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

[David Herrmann]

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.

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)

Thanks
David