On Thu, Jan 11, 2018, 20:11 Uoti Urpala <uoti.urp...@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 <graw...@gmail.com> Sent from my phone
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
