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

[Zbigniew Jędrzejewski-Szmek]

On Sun, Oct 19, 2014 at 12:43:59PM +0200, Colin Guthrie wrote:
> David Herrmann wrote on 19/10/14 12:05:
> > Hi
> > 
> > On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> >> Hi,
> >>
> >> How soon after login can I rely on systemd --user having reached
> >> sockets.target?
> >>
> >> This feels a bit like a "you shouldn't rely on that point in time..."
> >> type answer is warrented, and when e.g. GNOME or KDE sessions fully use
> >> systemd to bring themselves up it won't be an issue, but right now,
> >> systemd --user is started by (I think) PAM.
> >>
> >> 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.

Zbyszek