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

[David Herrmann]

Hi

On Sun, Oct 19, 2014 at 3:58 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at 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 <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.

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