Skip to main content ↑ ↓
Topic: Where best to start dinit from for user services? (Read 1087 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Where best to start dinit from for user services?

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?

Re: Where best to start dinit from for user services?

Reply #1 –
Bumping to clarify how to actually set up turnstile/dinit-userservd since I have not had much luck previously in setting that up and getting it to work so far. How do I go about doing so to make sure my user instance of dinit gets managed by the initial system instance?

Re: Where best to start dinit from for user services?

Reply #2 –
From the documentation:

Quote
The project consists of a daemon and a PAM module. The PAM module is enabled for example by adding this in your login path:

Code: [Select]
session optional pam_dinit_userservd.so

The daemon must simply be running in some way. If it is not running, you will still be able to log in with the above setup, but it will not do anything.

A recommended way to manage the daemon is using a dinit service that is provided with the project.

By "in your login path" it means in the /etc/pam.d/login file.

That should be all you need, other than setting up your user services.

Re: Where best to start dinit from for user services?

Reply #3 –
Fair enough, though I feel like I failed up until now to specify that I've been adhering — probably too much for my own good — to the XDG base dir spec and trying to use those environment variables within my script definitions. For example, this is my current script to start a D-Bus user session.

Code: [Select]
type = process
load-options = sub-vars
logfile = $XDG_STATE_HOME/dinit/dbus-session.log
command = $XDG_CONFIG_HOME/dinit.d/scripts/dbus-session --print-address 3
smooth-recovery=true
ready-notification = pipefd:3

How would I go about specifying these variables to be recognised by the running user instance under dinit-userservd?

Re: Where best to start dinit from for user services?

Reply #4 –
I'm not sure those variables are guaranteed to be set, at all. Applications are supposed to use their values if they are set or use a default if not. (Are they set in your terminal?) Elogind manages XDG_RUNTIME_DIR but not, I think, the others.

Therefore, you probably shouldn't use them unconditionally in file paths.

There are some example services here: https://github.com/Xynonners/dinit-userservd-services/tree/main/services

Re: Where best to start dinit from for user services?

Reply #5 –
Alright then, thank you. Changing those variables to what they would normally default to — and I do normally have those variables defined in my .bash_profile — did the trick, and now dinit-userservd seems to work. I still wish it were possible to use those variables directly but it's not really urgent for now.

What I would like to do eventually is figure out how to get the more current turnstile to work on an Artix installation, though that one when set up never seemed to even run a user instance of dinit upon logging in. Maybe there's still some crucial step I'm missing with that one aside from "build and install, enable the PAM module and service and restart".