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

[Damien Robert]

>From Zbigniew Jędrzejewski-Szmek, Thu 23 Oct 2014 at 17:26:57 (+0200) :
> > 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.

I was more thinking of having a default.target that is even smaller than
basic.target, but I forgot that we may want pam_systemd to start a session
different from the synced session before login, so this also conflates two
different use of default.target.

> 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.

Yes, this would be ideal. This way
- pam_systemd starts default.target
- the login returns when user-login.target is reached.
[the question is what happen is default.target does not pull
user-login.target; and I would argue that the login should return
immediatly rather than wait for default.target]

The important thing for me is that I may want default.target to be even
smaller than basic.target; and I thought that syncing on basic.target would
necessarily means launching it at each session, but maybe the
implementation could be carefull about that. So in a scheme where
- pam_systemd starts default.target
- the login returns when basic.target is reached OR returns immediatly if
  basic.target is not pulled in
I would be equally happy.

The proposal by Zbigniew has my preference because it is more flexible,
and does not conflates these three different things:
- when to return for the login (user-login.target)
- what services we want to launch by default (default.target)
- when standard basic setup is considered done (basic.target)

And unlike the system case where I always want default.target to requires
basic.target, in the user case I may want default.target to be smaller than
basic.target (for cron jobs I don't want my timers to launch); but still
requires basic.target when I launch say xfce.target.