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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 20, 2014 at 07:07:05PM +0200, Lennart Poettering wrote:
> On Mon, 20.10.14 11:02, David Herrmann (dh.herrmann at gmail.com) wrote:
> 
> > >> >> I want to rely on systemd --user to handle PulseAudio's activation
> > >> >> (ditching the built in stuff) and but I'm worried that e.g. GNOME or KDE
> > >> >> might start up their own session stuff and spawn some PA consuming
> > >> >> process before systemd --user has reached it's sockets.target and is
> > >> >> thus ready and listening on PA's native socket.
> > >> >>
> > >> >> Doesn't seem to be a problem on my machine here (it's working really
> > >> >> nicely actually!) but figured I should ask here too.
> > >> >
> > >> > Ordering of user units is (see /usr/lib/systemd/user/):
> > >> > default.target after basic.target after sockets.target
> > >> >
> > >> > PAM creates sessions by calling into systemd's pam-module, which then
> > >> > uses CreateSession() (internal api!). This call does not return until
> > >> > the job of user at .service is done. `systemd --user` notifies READY=1
> > >> > only after "default.target" is ready.
> > > Hm, this seems a bit excessive, because default.target can take
> > > a while. basic.target would seem more natural.
> > 
> > No idea what the semantics here are. I mean the important fact is that
> > we block on _some_ target so you can order stuff before the PAM call
> > returns. Which target this is, I don't really care. But I don't think
> > we ever defined how the semantics for user-sessions are, anyway.
> > 
> > Btw., manager_check_finished() doesn't explicitly wait for
> > default.target, but instead waits for all jobs to be done. Not sure
> > why.. Anyway, this means any dynamically scheduled jobs will also
> > contribute to this delay.
> 
> Hmm, this actually appears broken the way it currently is
> implemented... We probably should really move sd_notify() earlier than
> just becoming idle. Long running cron-like jobs might really break
> things here.
> 
> I figure we should go for Zbigniew's suggestion to only wait for
> basic.target. Zbigniew?
Yeah.

Zbyszek