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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 20, 2014 at 05:01:14PM +0400, Andrei Borzenkov wrote:
> On Mon, Oct 20, 2014 at 4:47 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > On Mon, Oct 20, 2014 at 02:16:30PM +0400, Andrei Borzenkov wrote:
> >> On Mon, Oct 20, 2014 at 1:02 PM, David Herrmann <dh.herrmann at gmail.com> wrote:
> >> > Btw., manager_check_finished() doesn't explicitly wait for
> >> > default.target, but instead waits for all jobs to be done. Not sure
> >> > why..
> >>
> >> Because default.target can be reached long before all jobs that are
> >> part of transaction finish. Do not forget that Wants != After.
> > It's confusing, but being Wanted by a target automatically adds a
> > Before dependency.
> >
> 
> But not every unit is directly WantedBy default.target, right?
> default.target Wants A.service where A.service Wants B.service. Now
> B.service is pretty much on free run, not?
A.service will also have After=B quite often. Yes, it is true that
not everything has a temporaral dependency, but 'systemctl list-dependencies
--after default.target' gives a pretty dense tree.

> >> > Anyway, this means any dynamically scheduled jobs will also
> >> > contribute to this delay.
> >> >
> >>
> >> OTOH it means that if your service has "systemctl start
> >> other.service", other.service will contribute.
> >>
> >> I wonder - does it wait for *any* job or only for those started as
> >> part of initial transaction? Arguably, the latter would be the right
> >> semantic here, not?
> > I guess that it didn't matter too much so far, given that an "empty"
> > user session starts in tens of milliseconds. But not it's starting to
> > matter and we should define something sane here.
> >
> 
> I'm mostly concerned about system boot here to be honest ... the old
> recurring question - how can we know that boot is complete.

There's no real point where the boot is complete. For example, let's
say that you start some sync job at every boot that can take a couple
of hours. Who cares if this jobs is done or not, and whether it is
part of default.target? The imporant thing is that the system as a
whole is in a well defined state. The watchdogs are active and if
something "hangs" then it will be detected with timeouts and dependencies,
and handled appropriately. A single target for the whole system
is too coarse and not dynamic enough.

> > Allowing the initial transaction to complete is not good, becuase
> > if one adds a job like "fetch all my mail", "preload the cache", or
> > anything else which is perfectly reasonable but could take unbounded
> > time, the user will be blocked out.
> >
> > default.target is better, but still to much I think. We need the
> > equivalent of systemd-user-sessions.service or basic.target, that
> > would mean "basic user infrastracture is in place and a shell
> > or a graphical env can be launched, user sockets are open, even
> > if the services are not fully there yet".
> >
> > Zbyszek
> >
> >
>