On Sun, 2019-01-20 at 00:34 +0000, Jonathon Kowalski wrote: > On Sat, Jan 19, 2019 at 5:05 PM Uoti Urpala <uoti.urp...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
