On Mon, Oct 20, 2014 at 4:47 PM, Zbigniew Jędrzejewski-Szmek <zbys...@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.herrm...@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? >> > 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. > 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 > > _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
