[systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Lennart Poettering]

On Thu, 23.10.14 17:26, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> > order it after basic.target (which things are by default anyway)...
> > 
> > My proposal now, (which is the same Damien's as I understood him):
> > 
> > 1. pam_systemd should sync on default.target
> > 2. by default default.target should just be an alias to basic.target.
> > 
> > That way we have two things:
> > 
> > a) as basic.target pulls in all sockets and busnames we know that
> >    everything that needs to be listened on is listened on by the time
> >    PAM succeeds
> > 
> > b) if people really want they can change the default.target symlink to
> >    something else and thus add additional services into this, that may
> >    run after the sockets/busnames, but before PAM succeeds.
> > 
> > Makes sense?
> Not to me. It still potentially delays user login a lot, because
> it conflates things which should be started by default with things
> which should be started before login completes.
> 
> If I want to start a bunch of daemons whenever my systemd instance is
> running, I want to add them to default.target, that's what it is there
> for. I see a strong parallel with the system default.target: it
> specifies what should be launched on boot, but user logins are allowed
> much earlier.
> 
> Maybe this should be made explicit and PAM should wait for a new
> user-login.target, which by default will simply have Wants=basic.target,
> but the user is free to add additional dependencies if they want to
> have more stuff running before they are allowed to log in.

I see what you mean. But "user-" sounds like an unnecessary prefix, if
we are already in user context, no?

Maybe just "login.target"?

Lennart

-- 
Lennart Poettering, Red Hat