Where best to start dinit from for user services?

[62832]

Cross-posting from an Artix Linux forum thread.

I got done today switching my current main machine from runit to dinit since I found it to be a much nicer and faster init system. Since then, I've been wondering what the best place to start dinit from would be for user services.

Currently, my main machine runs KDE Plasma with SDDM enabled. On a virtual machine, I have a minimal setup with dwm and sx to start the graphical session without a display manager like SDDM. The latter starts dinit via sxrc before the window manager itself, while the former currently starts it from .bash_profile for lack of any better ideas.

Ideally, I'd want to start dinit from somewhere that's

• versatile (i.e. works for most configurations and systems regardless of DE/WM and DM/startx/sx choice)
• self-contained (i.e. from someplace within $HOME rather than anywhere that requires root permissions)

With that said, where would I be best off starting dinit from as opposed to a dinit & at the end of .bash_profile?

[Duncaen]

https://github.com/chimera-linux/turnstile if you want services start with login sessions, otherwise why not just always start a dinit instance from dinit for your user.

[62832]

So far attempted the following as a system-level script for starting dinit as my user (_), and I'm not sure I've quite gotten it yet. Where would I proceed from this point onwards?

type = process
command = dinit
smooth-recovery = true
logfile = /var/log/dinit/user-suite.log
waits-for = elogind
waits-for = tmpfs
run-as = _

$ dinitctl list
dinit-client: connecting to socket /run/user/1000/dinitctl: No such file or directory`

[Duncaen]

You are at least missing -u/--user for dinit.

[62832]

Same thing regardless of the -u flag added. This is also supposedly the default anyway if it isn't being run as root.

[Duncaen]

Ah right then it may be missing XDG_RUNTIME_DIR, resulting in a different socket path or not starting at all not sure or its not able to find the default service directory not sure, doesn't it log anything?

[62832]

Nothing is logged beyond the actual user scripts I have set up failing, presumably for the same reason you gave of XDG_RUNTIME_DIR missing at that time.

[davmac314]

So far attempted the following as a system-level script for starting dinit as my user (_), and I'm not sure I've quite gotten it yet. Where would I proceed from this point onwards?

Ok, the service description is in place, is the service actually started? I.e. did you either start it explicitly, or does something else depend on it (did you "enable" it?)? Have you checked that it's started using (for example) dinitctl status <service-name>?

Do you have at least a boot service set up for the user instance of dinit?

[62832]

Further to this, the log now outputs something different altogether to any of the services failing. Each time, I get the following:

dinit: In multiple cgroups, cannot determine cgroup root path
dinit: Error binding control socket: No such file or directory

[davmac314]

Further to this, the log now outputs something different altogether to any of the services failing. Each time, I get the following:

My guess is:

• XDG_RUNTIME_DIR is now set, via the environment file, but
• whatever directory it specifies doesn't exist.

What did you set XDG_RUNTIME_DIR to?

[davmac314]

If you set it to /run/user/1000 I suspect you'll find that's created when you login and does not exist prior.

The issue is really that you are trying to start a user dinit instance outside of any login session, so the normal login session environment hasn't been created. That's why dinit-userservd (or its newer incarnation turnstile) exists - it spawns the user instance of dinit within the login session.

If you want to run a user dinit instance directly from the system instance, as you're trying to do here, you probably should choose a control socket path explicitly (-p <socket-path> option to dinit) and then use that same path when you run dinitctl once you're logged in (again, -p <socket-path> option, or, set the DINIT_SOCKET_PATH environment variable to the path).

As an alternative, just run dinit from your login script (.profile or equivalent). Probably something like:
dinit -q -l <log-file-path> &

[davmac314]

To be clear, whatever <socket-path> you choose needs to be in a directory that exists when the user instance of dinit starts, and it needs to be accessible by your user.

As an alternative, just run dinit from your login script (.profile or equivalent)

I see that this is what you initially had when you opened the issue. It might be the best solution, in the long run, if you don't want to run dinit-userservd/turnstile.

[62832]

Fair enough. Thanks anyways for putting up with me this discussion. 😅

I may see about putting together a PKGBUILD for Turnstile for my personal use if need be.

[62832]

This should hopefully be the last I need to bump this discussion again, but I am continuing to make use of the Bash startup method as neither Turnstile nor the dinit-userservd fork have worked well for me with my current setup.

I am however curious, albeit as a complete layman, would it be feasible or even within scope to add the functionality to dinit itself to also manage, upon request, a user instance of itself when invoked as the system init? To wit, Obarun Linux's 66 service manager built on top of S6 has the boot-user@ module used for much the same purpose, allowing user services to be managed optionally alongside system-level services.

[davmac314]

I don't know enough about 66 works to give a comprehensive answer, and that documentation isn't very clear as to how it actually works. It's not clear if the user services are managed by the system instance, or if they run under a separate manager instance, and whether the user can configure their own services or whether this is just a means to configure at system level a set of services for specific individual users.

You asked whether dinit can manage a user instance of itself, but that's exactly what was happening when you created the user-suite service above, so I'm not sure if I understand correctly what you're asking. You could arrange that Dinit only started the user instance upon login, by not enabling user-suite to start at boot, and then running dinitctl start user-suite (as root) when logging in, which you could probably do from a PAM module (pam_exec). This might solve some of the problems you had (but in general, refer to the discussion above for details).