On Sun, 19.10.14 12:05, David Herrmann ([email protected]) wrote: > Hi > > On Fri, Oct 17, 2014 at 6:14 PM, Colin Guthrie <[email protected]> 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 [email protected] is done. `systemd --user` notifies READY=1 > only after "default.target" is ready. > > Long story short: The PAM module blocks until the user-manager is > ready. Therefore, sockets.target is loaded and ready. > > (I'm no expert in sd job handling, so maybe Lennart can confirm this)
I hereby confirm this. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
