Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: Tool to automatically start dinit for each new logged in user (Read 6762 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: Tool to automatically start dinit for each new logged in user

Reply #16 –
Any issues with disabling dinit-user-spawn if one doesn't pretend to trigger any daemon/service when getting their user logged in (non DE)?  I haven't noticed it being a dependency of other dinit daemons/services, however the package itself can't be removed, it's already buried as a dependency for a bunch of stuff.

I create /run/user/${UID} through rc.local, and I set all environment variables through ~/.bash_profile, and also there, just when under tty1 I trigger startx, which in turn runs some stuff and finally triggers the WM (i3wm with tabbed layout) I use through dbus-run-session so that all dbus environment variables gets spawned for the WM.  And the WM itself launches everything I need to get auto-started.

Even when I was using pipewire (I thankfully got rid of it by going back to x11, and I'm again happy with plain alsa) because it was a must for wayland screen sharing, I was triggering it from the compositor itself (sway with tabbed layout).

I guess there's a tendency to turn everything into services, even calling for the WM/DE, and therefore a bunch of new user logging services are required so that everything integrates on time.  I personally don't see a need for user login daemons/services given the way I launch stuff.  I see the need for me to start user daemons/services as user but a boot time (perhaps rc.local at least) for non interactive sort of rootless devices, but that's way different.

Would it be harmful to keep the service disabled?  Meaning, would eventually some other service break because of the lack of dinit-user-spawn?  I don't see how a service meant to monitor user logins would affect other services, but to be honest as it doesn't really monitor users logins but rather the creation of /run/user/${UID} per user, that might carry things mistakenly spawned from that service in my case, since I do create them just on rc.local, and that's the other reason I think it might also be good to disable it for me.

Re: Tool to automatically start dinit for each new logged in user

Reply #17 –
Quote from: kixik – on
Would it be harmful to keep the service disabled?

All dinit-user-spawn does is start a dinit instance for each user that logs in. If you require user services and do not already have an alternative method to handle such, then they won't work without it, but as you've mentioned you don't use any dinit user services (as you're launching them manually), it won't actually do anything for you and hence should be safe to disable.

Re: Tool to automatically start dinit for each new logged in user

Reply #18 –
Good start so far, I wouldn't mind this being a more stripped-down option for Artix over Turnstile. Unfortunately though, I ran into a problem just now which required me to switch back to Turnstile for the time being, and it's that my browser (Brave) refuses to use KDE's own file picker via portals instead of defaulting to GTK's (awful) file picker. I can only assume that maybe this is something to do with how the D-Bus user service is started up.

Furthermore, if I log in via e.g. an SSH session first, and then close that session and log in normally to my desktop session, the user instance of Dinit doesn't seem to start up properly.

Am I perhaps missing some extra bit of configuration, or would this have to be addressed upstream?

Re: Tool to automatically start dinit for each new logged in user

Reply #19 –
The way user logins are detected are via seeing if a new folder is added to /run/user. If so, then a new instance is started under that UID, and when removed the dinit process is terminated. I am unsure how ssh particularly interacts with /run/user.

For the former, I assume it is related to environment variables, of which need to be set via passing an environment file as dinit args in the toml configuration, or set within the service itself via the dinit service option.

Re: Tool to automatically start dinit for each new logged in user

Reply #20 –
Quote from: 90 – on
Good start so far, I wouldn't mind this being a more stripped-down option for Artix over Turnstile. Unfortunately though, I ran into a problem just now which required me to switch back to Turnstile for the time being, and it's that my browser (Brave) refuses to use KDE's own file picker via portals instead of defaulting to GTK's (awful) file picker. I can only assume that maybe this is something to do with how the D-Bus user service is started up.

@mobin2008 figured it out in another thread:

Quote from: mobin2008 – on
Turnstile is [...] exporting dbus session address into login environment.

dinit-user-spawn would need to hook into either (1) the shell profile (say, /etc/profile.d) (2) the login process itself/PAM (like Turnstile), to export its own DBUS_SESSION_BUS_ADDRESS. Configuring dinit-user-spawn itself wouldn't help because it won't propagate to your DE (plus, the dbus service Artix packages already exports the dbus environment variable to other dinit services itself).

Re: Tool to automatically start dinit for each new logged in user

Reply #21 –
Please forgive me if I shouldn't reply here. Today I discovered that I cannot continue to use turnstile because Arch refuses to upgrade any other packages if I don't accept dinit-user-spawn instead.  So fearing a lack of security updates I was forced to accept it and after a reboot my sound stopped working (pipewire etc not starting).

It wasn't enabled. So FWIW if anyone else has the same problem: 
 
    sudo dinitctl enable dinit-user-spawn

.... is what helped me.
 

Re: Tool to automatically start dinit for each new logged in user

Reply #22 –
@tsuro Weird, it's been a week since dinit-user-spawn stopped being a mandatory part of dinit-rc. You could (as I was able to) upgrade without being forced to migrate to dinit-user-spawn. See here.

You can migrate back to turnstile-dinit if you prefer.