openrc-user-pam: skip initialization for users without a login shell

[vixalien]

When openrc-user-pam is installed on alpine, openrc will try (hopefully) to run the openrc services for the GDM and greetd users whenever their respective login manager starts.

This will eventually fail after 3 tries, and it will fail anyway, because those users have /bin/nologin or /usr/bin/nologin as their login shell.

It would be nice if these tries were not done at all, as it wastes a small amount of time while trying to boot up the laptop quickly.

A better alternative would be to support launching user services even if the login shell was set to nologin but not sure if that's possible

/cc @navi-desu

[navi-desu]

A better alternative would be to support launching user services even if the login shell was set to nologin but not sure if that's possible

we could default to /bin/sh if the user's shell is nologin (better yet would be to not rely on the user's shell at all but that's not doable yet)

this would require that pam sets up XDG_RUNTIME_DIR, which is what alpine does already anyway

[navi-desu]

if you could test #944, it adds a check for /etc/shells

alternatively, we could add an option to conf.d/user that overwrites the shell to use, and thus could be set in conf.d/user.gdm

[N-R-K]

It would be nice if these tries were not done at all

Are you looking for some way to disable auto launching the user service for certain users?

We have an option in /etc/rc.conf to disable auto launch completely but no way to blacklist/whitelist only specific users. Could be a good addition if there's demand for it, but I'm not entirely clear if that's what you're looking for or not.

[navi-desu]

Are you looking for some way to disable auto launching the user service for certain users?

i'd like to have a general "mask" service by symlinking it to /dev/null, similar to systemd, so disabling per-service auto-launch would be 'ln -s /dev/null /etc/init.d/user.$USER'

trying to do that currently throws an error of "can't execute", so to do that officially, we'd need to have that failure mode cleaner (detected masked services during dependency resolution, fail cleanly in pam_openrc, and proper error message when attempting to execute it by hand)

[navi-desu]

(i think i misunderstood the question)

either way gdm will eventually need user services (for gnome-session 49), so #944 will still be necessary

for greetd, then we need the masking feature

[navi-desu]

(shouldn't have been closed. github, i changed Fixes: to Bug: in the commit message, i hate github)

[airtower-luna]

for greetd, then we need the masking feature

Not necessarily, depending on the greeter. E.g. phrog needs dbus, and starting that in a user session would avoid leaking a dbus instance on service restart.