[systemd-devel] Conflation of propagation in dependencies creates race windows

Uoti Urpala uoti.urpala at pp1.inet.fi
Sun Jan 20 02:59:15 UTC 2019


On Sun, 2019-01-20 at 00:34 +0000, Jonathon Kowalski wrote:
> On Sat, Jan 19, 2019 at 5:05 PM Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > I think you're wrong here. It makes perfect sense that if unit A has
> > Requires= for another unit, stopping that required unit which A can't
> > work without will stop A too. Removing that logic is not a good
> > solution.

> I am NOT advocating for changing how Requires= currently works, and
> also, no many people by accident use Requires= for its semantics at
> startup.

So what exactly are you saying instead? That this case shouldn't use
Requires= (would be a bad idea, not an appropriate solution to the
actual problem)? That you made a mistake when you brought up this case,
nothing you say is actually relevant to it, and none of your proposed
changes would help solve this issue? Something else you haven't
explained?


> Also, this cannot work. Suppose I have Restart=on-failure in service,
> and service exits on its own normally. How will systemd decide X
> should not be stopped, in case an ExecStop* statement ends up failing,
> and then it *should* restart our service? All of this is going to be
> very racy and undeterministic.

Systemd could consider X "unneeded" only when Y is not active, has
nothing executing, and has nothing scheduled to execute. This does not
seem racy or undeterministic.

Anyway, the only realistic alternatives are to either restart X
automatically when Y restarts, or leave Y stopped after all. Restarting
Y while leaving X stopped is not a sane alternative (if the user wants
to allow that, it should be Wants= instead of Requires=). So this still
requires some solution, and nothing you have proposed would help at
all.




More information about the systemd-devel mailing list