On Tue, 2015-05-19 at 01:26 +0200, Lennart Poettering wrote: > On Tue, 19.05.15 00:55, Lennart Poettering (lenn...@poettering.net) wrote: > > On Thu, 14.05.15 21:23, Evert (evert.gen...@planet.nl) wrote: > > > According to the systemd documentation, Requisite disallows starting a > > > unit unless the specified unit has been started. This seems to work > > > fine, however, if the specified unit has been restarted, this unit will > > > be started too! > > > This is not what should happen and it doesn't happen with a stop and > > > start of the specified unit, so clearly, restart behaves different than > > > stop followed by start.
> > "systemctl stop" by the user. Now, as a special shortcut we currently map > > "Requisite=" and "Required=" to a reverse dependency of > > "RequiredBy=", which is problematichere, since we'll hence make no > > distinction between the two when processing "systemctl stop". > > > > I figure we need to split up the reverse dep here, and introduce a > > seperate RequisiteBy= dependency so that we can avoid this problem... > > Fixed in git. Please verify. I think you're talking about something quite different than the problem described by Evert. The bug report was about a currently stopped depending unit being started by actions on a depended-on unit, which is equally wrong for either "Requires=" or "Requisite=", and is no reason for adding any new distinction between them! And the problem was also about "systemctl restart", while "systemctl stop" worked as expected. Did your change disable propagation of STOP from depended-on unit to the one using "Requisite="? If so, I think that's wrong and should be reverted - the documentation says Requisite is "similar to Requires=", and gives no reason to expect that propagation in the direction from the depended-on unit to the depending-on unit would be affected. As for Evert's original problem, I think it's that RESTART is propagated to all RequiredBy units unconditionally - even if those are currently stopped! This affects both Requires= and Requisite= in exactly the same way. The problem is not easily visible because systemd aggressively garbage collects units that are not active, and RequiredBy only exists when the requiring unit is loaded; this means currently stopped units are usually hidden from the logic that could incorrectly start them. But if there is some other reason to keep the unit loaded, then the bug is visible. A configuration like this should be sufficient to reproduce: a1.service is arbitrary a2.service has Requires=a1.service a3.service has OnFailure=a1.service a2.service Keep a3.service running to ensure that the OnFailure references keep everything else loaded. Leave a2.service stopped. Restart a1.service; this will start a2.service (via propagated restart), when it clearly should not. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel