[systemd-devel] systemctl start second.service first.service

[Mantas Mikulėnas]

On Thu, Jan 11, 2018, 20:11 Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:

> On Thu, 2018-01-11 at 15:34 +0100, Reindl Harald wrote:
> > Am 11.01.2018 um 15:25 schrieb Uoti Urpala:
> > > I'd guess this is due to systemctl starting each listed unit
> > > independently rather than as a single transaction. Thus, the second
> > > version first starts second.service without first.service being active
> > > at all. Since there's only an After relationship, not Wants/Requires,
> > > second.service will immediately start. Then systemctl starts
> > > first.service; since second.service is already running, there's nothing
> > > the After relationship could affect
> >
> > but why?
> >
> > the one "After=" should be enough to have a clear ordering of stop/start
> > both as it happens in shutdown/boot
>
> At boot, both would be started as part of the same transaction (same
> would happen here if you started a third.service that depended on both
> first.service and second.service, then second.service would always
> wait). Here second.service is just started individually, and systemd
> has no idea at that time that first.service is going to be running at
> all. Given that, it really can't behave any differently (it can't delay
> the start of second.service to wait for first.service, when as far as
> it knows first.service may well never get started at all!). It's only
> after second.service is already running that it sees that first.service
> will be started, and at that point it's too late to make second.service
> wait. There really is nothing the init portion could do differently
> given the semantics of bare "After" (the behavior could be changed in
> the systemctl binary).


It could, if there was an API call to start multiple jobs at once.
(Actually, isn't there one already?...)
-- 

Mantas Mikulėnas <grawity at gmail.com>
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180111/6a9e0bc6/attachment.html>