Good Afternoon,
I have developed a tool, dinit-user-spawn, https://github.com/initMayday/dinit-user-spawn, of which automatically starts a dinit process for each user that has logged in, allowing each user to have their own user services with ease. Recently, I released the first master (ie. stable) release, and hence I believe this build is fine for others to use (a few others have tested the development branch before its promotion to master/stable, but of course more testing from others would be appreciated). The way the program works is quite simple and comes in at around 500 lines of c++ code and hence should be readable by most who understand c++. How it precisely works is also explained in the README.
The master release is on the AUR, for those who wish to try: https://aur.archlinux.org/packages/dinit-user-spawn-master-git
If also possible, i think it would make a good addition to the wiki for the dinit installation. The main reason i created this over turnstile is that it is more adjacent in functionality to turnstile's original goal where it was initially known dinit-userservd, and before it expanded its scope to become a logind replacement, of which it has not yet accomplished. With the last update to it being 7 months ago and with only relatively minor commits in the months leading upto the last commit (considering that its goal has not yet been reached), I thought a project with more limited scope of which is much more easily achievable (which it has done) was warranted for purely spawning dinit as a user process for each user.
Thank you.
I was running turnstile (just to try it out as i run most of my services etc system wide) and it was OK, or at least seemed to be. However, saw this and thought i'd at least try it out, especially as it seems simpler (that's my assumption) than turnstiled. So, disabled all the turnstiled stuff, installed this and enabled and yeah, seems to be running and doing exactly what it was designed to do.... Nice one.
As soon as i find something that i can run as a user service i'll try it out properly. Many thanks and kudos to you for making it happen. Dinit is a such a great init system, i'm hoping that more people will see that and start using it. :)
I will package this for the world repo.
@initMayday Could you please make a git tag for the upcoming package?
Good evening,
Zendjinn: glad you have found the program useful, and yes it is much simpler than turnstile, as much more akin to turnstile's original goal and name of dinit-userservd, before it expanded to attempt to replace all of logind. The scope is much more limited to what it says on the tin.
artoo: Sure thing, I believe I have done so just now (https://github.com/initMayday/dinit-user-spawn/releases/tag/v1.0.0), however, let me know if anything further needs to be done. Just to note, the master branch is always stable (work is only done on the dev branch before eventual promotion to master)
Thank you.
It is more for packaging purposes/rules to pull a tag.
Your neat tool is precisely the kind of "trickery" dinit needed to match a current openrc. :)
https://gitea.artixlinux.org/packages/dinit-user-spawn
Maybe integrate the service install as meson option?
That is the only slight improvement I see from deployment side.
Next I will test it.
I think it is better to have the service within the PKGBUILD, although that should probably be split off into a separate package called dinit-user-spawn-dinit, as nothing inherently ties this program to having dinit as the main init system. Technically it would work just fine to start dinit for each user no matter the root init system (i can't imagine people doing this though). Perhaps other distros may also have different preferred locations for the dinit service directory, so it is just a bit more modular incase other distros want to package it.
(Incase you haven't seen it, the PKGBUILD builder is found at: https://github.com/initMayday/dinit-user-spawn/blob/dev/packages/make-packages.sh, and uses https://github.com/initMayday/dinit-user-spawn/blob/dev/packages/template/PKGBUILD, may be useful for your own)
I integrated dinit-user-spawn via alpm hooks in current gremlins dinit packages.
Plesae test.
The dinit-user-spawn service is enabled on install by alpm hook.
1. It doesn't work with startx in .bash_profile
2. Why make such stuff as hard dependency?
UPD:
It actually works with auto startx but it takes 2 minutes to start the service.
I don't see why you'd even want to start this alongside X11 (or even within your shell) and not simply via a system service such as the one provided under Dinit. I have a good few user services myself at the moment that are independent of a display server (e.g. dbus, pipewire), and I personally always thought it'd be a better idea to start those immediately upon login. I could be wrong, though.
If you don't want the hook to be used you can create a symlink, with the same name, to /dev/null in /etc/pacman.d/hooks
I do start it as system service (sudo dinitctl enable blahblahblah), but for whatever reason it has issues when .bash_profile contains startx.
https://wiki.archlinux.org/title/Xinit#Autostart_X_at_login
No problems with hook, but the util itself isn't working properly, whick is a pity.
It is likely because of environment variables, when you start dinit as your user manually it inherits your env vars, including everything set at runtime. dinit-user-spawn is unable to do as such (since it doesn't inherit from your shell), and can only get env vars as far as su - yourusername -c "env" can give it, which is usually a subset (although if you know what the env var should be if you set it such that env logs it, it'll inherit from that, Note if anyone does have an idea of how to easily get the full set of env vars as from the shell, feel free to contribute such).
Beyond this for dinit services, you can provide your service an environment file (see docs: https://davmac.org/projects/dinit/man-pages-html/dinit-service.5.html#env), which seems to be the more official way of doing things.
Ultimately, the easiest way of gaining full control is to simply launch dinit from your bashrc or other equivalent.
If it is not env vars, then dinit-user-spawn quite literally only starts the dinit process for each user that logs in (and cleans it up), so if the dinit process itself is running, then it has completed its task.
Although, nothing should really have a hard dependency on dinit-user-spawn, as the manual method of launching it yourself offers you more control (and works perfectly fine), albeit at a bit less convenience.
Yes, this is it.
That's how I do it. I launch user instance of dinit from .bash_profile:
pgrep -u "$USER" -x "dinit -q" > /dev/null || { dinit -q & }
trap "dinitctl shutdown" EXITBut I like the idea of dinit-user-spawn. ;)
Yeah dinit-user-spawn seems a bit more "pure" but i think the ultimate solution is to just strip down the program (or even create a new bash script, which would be very minimal even compared to dinit-user-spawn) such that it autocreates your ~/dinit.d and such, and appends (with confirmation) to your bashrc or such the command to launch dinit.
This of course is slightly manual, but not to much of a great degree since the script automates it and just prompts you to accept, and of course you'd have to live with your bashrc or equivalent having a command to launch dinit, but this mitigates all issues associated with environment variables in a very understandable manner with no 'hacks', and I personally would see it as a successor to dinit-user-spawn as it is more powerful since you have direct control over the dinit launch (although it is less 'clean').
Ultimately davmac should ideally add proper user service support to dinit, although i don't see this happening as it is said to not suggest features unless you will add them on his github, indicating to me that the project is more in maintenance mode (especially with what i perceive as burnout in his older blogs). Hence I don't think it is for the best that dinit-user-spawn is made a hard dependency on other stuff, as it locks people out of the, what I perceive to be, superior bash launch method (which comes at the cost of a bit of convenience).
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.
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.
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?
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.
@mobin2008 figured it out in another thread:
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 (https://gitea.artixlinux.org/packages/dbus-dinit/src/commit/ea6ac680522ad51189332274b38097be792b7c3c/dbus.user.script#L3) itself).
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.
@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 (https://forum.artixlinux.org/index.php/topic,8549.msg51580.html#msg51580).
You can migrate back to
turnstile-dinit if you prefer.