Hi On Sun, Oct 19, 2014 at 3:58 PM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > 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 <gm...@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@.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. Thanks David _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
