Feature Req: user daemon autostart / pam module

[EmiOnFlux]

currently dinit does not have a native way to autostart the user daemon when a user is logging in, there are external tools that can autostart the daemon but they either depend on things like elogind and dbus or do way more than just starting the user daemon.

It would be great to have an inbuilt way to autostart the user daemon upon login similar to other init systems like OpenRC and SystemD

Im currently woking on maintaining dinit as an init option for gentoo via the gentoo user repository (GURU)
If this is a wanted feature i could potentially do the changes on my own and make a PR however no promises in that regard as i am not very skilled with C++

[softexpert]

On Artix I can address this need by using userspawn.
Hope it helps ...

[davmac314]

there are external tools that can autostart the daemon but they [...] do way more than just starting the user daemon

I don't think this is really a correct characterisation of turnstile - it mainly starts the user services daemon and only some very minimal other things that are generally necessary anyway. To avoid dependency on elogind I'd suggest just going with turnstile.

I don't think we need anything that's an integral part of Dinit for this, given the existence of external options.

[EmiOnFlux]

I don't think this is really a correct characterisation of turnstile - it mainly starts the user services daemon and only some very minimal other things that are generally necessary anyway. To avoid dependency on elogind I'd suggest just going with turnstile.

I feel like if you are a distro with a singular option of just dinit + turnstile that might work great but if it’s a distro where customisation is a major aspect things get messy some people might prefer to use elogind or even have to use it, given that turnstiles goal is to ultimately replace logind and is already doing some stuff that logind is doing you essentially have 2 tools doing the same job just to start the daemon so the better option would like be to also package userspawn when elogind is used but then what if people don’t use a session tracker at all

Do correct me if I’m wrong but a small pam module to start the daemon is also not a very big change OpenRC for reference.

I don't think we need anything that's an integral part of Dinit for this, given the existence of external options.

I don’t think “external options” in the usual case applies here, the external tools exist as more of a hacky solution for init systems that lack the ability to start their user daemons on their own, and I feel like in the future having to rely on external tools for such a crucial job will become a headache if more people adopt dinit given that you now rely on other tools that each could have their own issues and users will have to navigate between the projects to figure out where to report the bugs

[davmac314]

turnstiles [...] is already doing some stuff that logind is doing

It optionally creates a runtime directory (XDG_RUNTIME_DIR) and sets one or two environment variable values. I think that's about all? Since it's optional you can use it in combination with elogind, no problem.

the external tools exist as more of a hacky solution

In the case of turnstile, it already consists of pam module which is used to start the user instance on login. I don't see how that's any more "hacky" than doing the same thing as a module that lives inside the Dinit source tree. Sorry, but I just don't see the need for this is an integrated Dinit component. Part of the whole Dinit design philosophy is to be possible to integrate with other tools, rather than try to do everything in Dinit itself.

You are welcome of course to create a simpler program (than turnstile) to do the same thing, of course - I just don't have interest in doing so myself (and am not keen on you creating a PR if you lack the necessary skill; that would likely eat up even more of my time). However if you can do this yoursefl I'd be fine with hosting anything you create inside the "contrib" directory within the Dinit source tree.

[EmiOnFlux]

turnstiles [...] is already doing some stuff that logind is doing

It optionally creates a runtime directory (XDG_RUNTIME_DIR) and sets one or two environment variable values. I think that's about all? Since it's optional you can use it in combination with elogind, no problem.

That is true ATM, but from what i understand they plan to be a full replacement to logind in the future so it would cause problems in the future

You are welcome of course to create a simpler program (than turnstile) to do the same thing, of course - I just don't have interest in doing so myself (and am not keen on you creating a PR if you lack the necessary skill; that would likely eat up even more of my time). However if you can do this yoursefl I'd be fine with hosting anything you create inside the "contrib" directory within the Dinit source tree.

Thanks that's a good idea, i will look making a small program that does myself might take while though

[softexpert]

@EmiOnFlux : userspawn is installed as a dinit service at system level, and will detect when a user logs in, then will execute a process (of your choice) - which can be the user instance of dinit.
It does not depend on anything else and requires dbus to be active at system level.

Here is the dinit service description file for userspawn:

type = process
command = /usr/bin/userspawn
depends-on = login.target
restart = true
log-type = buffer
log-buffer-size = 1000000 # 1 MB

You would need to create a file (/etc/xdg/userspawn/userspawnrc) containing:

#!/bin/bash

#> Create the dinit.d directory, and related files, if it doesn't exist already
if [ ! -d "$HOME/.config/dinit.d" ]; then
    mkdir -p "$HOME/.config/dinit.d/boot.d" && \
    echo -e "type = internal\nwaits-for.d: ./boot.d/" > "$HOME/.config/dinit.d/boot"
fi
exec dinit --user

I would say that it fits your use case.

[EmiOnFlux]

@EmiOnFlux : userspawn is installed as a dinit service at system level, and will detect when a user logs in, then will execute a process (of your choice) - which can be the user instance of dinit. It does not depend on anything else and requires dbus to be active at system level.
[..]
I would say that it fits your use case.

From the README of the userspawn repo:

userspawn works in conjunction with (e)logind, and hence, dbus. It listens for users being added or removed. For every user addition, a new cgroup is created for that user and .userspawnrc is spawned into that cgroup. Upon user removal, that cgroup is then cleaned up, as triggered by (e)logind.

So it does depend on elogind and dbus which is what im trying to avoid, while also not conflicting elogind in the future (which would be the case with turnstile)

[softexpert]

dbus is needed to detect when the user logs in.

elogind is mentioned because on Artix it provides a required dependency for polkit and the author needed to ensure that dependency, but it is not required to make userspawn run.

On my system, I'm using seatd instead of elogind.

[EmiOnFlux]

dbus is needed to detect when the user logs in.

elogind is mentioned because on Artix it provides a required dependency for polkit.

I'm using seatd instead of elogind.

It also needs elogind or another login manager to be running
It uses dbus for the org.freedesktop.login1.Manager interface and listens to new logins
Without elogind running it doesn't have anything to listen to

[softexpert]

Then I'm not sure I understand exactly what you need to achieve.
I'm curious about your config - definitely I can learn something here.

You still need a login manager; what are you using currently?
You still need dbus on your system; are you using something else?

[EmiOnFlux]

Then I'm not sure I understand exactly what you need to achieve. I'm curious about your config - definitely I can learn something here.

You still need a login manager; what are you using currently? You still need dbus on your system; are you using something else?

The goal i'm trying to archive is being able to have user services autostart without forcing users into using elogind or dbus, and without causing conflicts in the future (given that turnstile's end goal is to be a logind replacement)

[softexpert]

OK, it was not clear for me that you also want to avoid dbus.

In this case userspawn is not useful for your scenario, sorry for having insisted with it.

Does your login manager can trigger the execution of a script when the user opens a session?

[EmiOnFlux]

Does your login manager can trigger the execution of a script when the user opens a session?

I think you're misunderstanding me a bit, i am not trying to find something for my specifc use case
I'm working on maintaining dinit as an init option for gentoo via the gentoo user repository, so i am trying to find a solution that will work in all/most usecases and not just one

[softexpert]

This would require dinit (or something else) to detect when a user logs in and start a user-level instance of dinit, right?

Why not modify the login manager's scripts to perform an exec dinit --user ?
It would not depend on dbus; but it would depend on the login-manager...