Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, May 19, 2015 at 1:26 AM, Lennart Poettering lenn...@poettering.net 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: Hi, 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. Hmm, I figure this is a bug in systemd. Whenever you have a unit A declare a Requisite= on a unit B then this will actually create two dependencies: the actual Requisite= one plus one in the opposite direction, of type RequiredBy=. Dependencies of type RequiredBy= are mostly internal to systemd, you cannot configure them directly (though you can query them using systemctl show). They are used to track down what to stop when we get 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. The commit be7d9ff730cb88d7c6a869dd5c47754c78ceaef2 (core: introduce seperate reverse dependencies for Requires= and Requisite=) introduced a regression in rkt: the container does not stop anymore when the main service terminates. In my test, grep says we have one unit using a Requisite* option (systemd-update-utmp-runlevel.service). The main unit file uses one Requires option: == sha512-0543bc3759cd76d21d8605cd55e19bea.service == [Unit] Description=coreos.com/rkt-inspect DefaultDependencies=false OnFailureJobMode=isolate OnFailure=reaper.service Wants=exit-watcher.service Requires=prepare-app@-opt-stage2-sha512\x2d0543bc3759cd76d21d8605cd55e19bea-rootfs.service After=prepare-app@-opt-stage2-sha512\x2d0543bc3759cd76d21d8605cd55e19bea-rootfs.service [Service] Restart=no ExecStart=/diagexec /opt/stage2/sha512-0543bc3759cd76d21d8605cd55e19bea/rootfs / /rkt/env/sha512-0543bc3759cd76d21d8605cd55e19bea 0 0 /inspect -print-msg=Hellooo -sleep=3 User=0 Group=0 I am trying to understand the regression... it's possible that it is rkt using systemd incorrectly. Cheers, Alban ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
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
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, May 19, 2015 at 2:15 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: 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. Exactly. At least I do not see anything obvious in code that would check whether dependent units are running or not. And try-restart is pure forntend option which is not propagated to systemd manager itself. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 19.05.15 14:15, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: 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. Hmm, you might have a point. But I figure we should still split the reverse of requisite and requires (simply because it is confusing when looking at systemctl show), so I think I'll leave that part in, but otoh i'll make sure the two backwards deps work the same way again... 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. Hmm, so basically you are saying that currently RESTART is propagated as RESTART to all depending units, but you suggest that it should be propagated as TRY_RESTART? Did I get this right? That does make sense indeed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, May 19, 2015 at 3:44 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 19.05.15 13:08, Alban Crequy (al...@endocode.com) wrote: The commit be7d9ff730cb88d7c6a869dd5c47754c78ceaef2 (core: introduce seperate reverse dependencies for Requires= and Requisite=) introduced a regression in rkt: the container does not stop anymore when the main service terminates. In my test, grep says we have one unit using a Requisite* option (systemd-update-utmp-runlevel.service). The main unit file uses one Requires option: I have the suspicion that f3b85044c845de03de05135c1dd5f3298bf3e5a2 might fix your issue, can you check? Yes, it works now. Thanks! (only if you have units that use StopWhenUnneeded=yes, otherwise it's a different issue) Yes, there was a unit with StopWhenUnneeded=yes. Cheers, Alban ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 19.05.15 13:08, Alban Crequy (al...@endocode.com) wrote: The commit be7d9ff730cb88d7c6a869dd5c47754c78ceaef2 (core: introduce seperate reverse dependencies for Requires= and Requisite=) introduced a regression in rkt: the container does not stop anymore when the main service terminates. In my test, grep says we have one unit using a Requisite* option (systemd-update-utmp-runlevel.service). The main unit file uses one Requires option: I have the suspicion that f3b85044c845de03de05135c1dd5f3298bf3e5a2 might fix your issue, can you check? (only if you have units that use StopWhenUnneeded=yes, otherwise it's a different issue) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
В Tue, 19 May 2015 14:07:21 +0200 Lennart Poettering lenn...@poettering.net пишет: On Tue, 19.05.15 14:26, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Tue, May 19, 2015 at 2:15 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: 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. Exactly. At least I do not see anything obvious in code that would check whether dependent units are running or not. And try-restart is pure forntend option which is not propagated to systemd manager itself. Hmm? We do have JOB_TRY_RESTART while putting together the transaction... What do you mean? I was referring to this comment. May be I misunderstood it. But I do not see TRY_RESTART where dependent units are processed either. /* JOB_TRY_RESTART can never appear in a transaction, because * it always collapses into JOB_RESTART or JOB_NOP before entering. * Thus we never need to merge it with anything. */ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 2015-05-19 at 14:06 +0200, Lennart Poettering wrote: On Tue, 19.05.15 14:15, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: 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 Hmm, so basically you are saying that currently RESTART is propagated as RESTART to all depending units, but you suggest that it should be propagated as TRY_RESTART? Did I get this right? Yes, I think that should fix it. I feel that a TRY_RESTART style true restart would be a more natural base operation than the current either start or restart one, with the START_OR_RESTART for systemctl restart semantics collapsing to either START or RESTART. With that terminology, the logic would simply be that RESTART is propagated, START is not. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 19.05.15 20:13, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Tue, 19 May 2015 14:07:21 +0200 Lennart Poettering lenn...@poettering.net пишет: On Tue, 19.05.15 14:26, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Tue, May 19, 2015 at 2:15 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: 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. Exactly. At least I do not see anything obvious in code that would check whether dependent units are running or not. And try-restart is pure forntend option which is not propagated to systemd manager itself. Hmm? We do have JOB_TRY_RESTART while putting together the transaction... What do you mean? I was referring to this comment. May be I misunderstood it. But I do not see TRY_RESTART where dependent units are processed either. /* JOB_TRY_RESTART can never appear in a transaction, because * it always collapses into JOB_RESTART or JOB_NOP before entering. * Thus we never need to merge it with anything. */ True. The code I commited now uses job_type_collapse to fix the job type up as necessary. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 19.05.15 14:15, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: 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. I have now reverted this with a1036fd1b0c195a63c983db67024d4b725f0166c. Please check. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Thu, 14.05.15 21:23, Evert (evert.gen...@planet.nl) wrote: Hi, 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. Hmm, I figure this is a bug in systemd. Whenever you have a unit A declare a Requisite= on a unit B then this will actually create two dependencies: the actual Requisite= one plus one in the opposite direction, of type RequiredBy=. Dependencies of type RequiredBy= are mostly internal to systemd, you cannot configure them directly (though you can query them using systemctl show). They are used to track down what to stop when we get 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... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
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: Hi, 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. Hmm, I figure this is a bug in systemd. Whenever you have a unit A declare a Requisite= on a unit B then this will actually create two dependencies: the actual Requisite= one plus one in the opposite direction, of type RequiredBy=. Dependencies of type RequiredBy= are mostly internal to systemd, you cannot configure them directly (though you can query them using systemctl show). They are used to track down what to stop when we get 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. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On 15-05-15 07:05, Andrei Borzenkov wrote: В Thu, 14 May 2015 21:23:38 +0200 Evert пишет: Hi, 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. This can easily be reproduced using 2 dummy service units: # dummy-1.service: [Unit] Description=dummy one DefaultDependencies=false After=local-fs.target Before=basic.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/true ExecReload=/bin/true ExecStop=/bin/true [Install] WantedBy=sysinit.target multi-user.target Also=dummy-2.service # dummy-2.service [Unit] Description=dummy TWO DefaultDependencies=no After=dummy-1.service Before=shutdown.target Requisite=dummy-1.service [Service] Type=oneshot RemainAfterExit=no ExecStart=/bin/true [Install] WantedBy=shutdown.target # systemctl daemon-reload # systemctl enable dummy-1 Created symlink from /etc/systemd/system/sysinit.target.wants/dummy-1.service to /etc/systemd/system/dummy-1.service. Created symlink from /etc/systemd/system/multi-user.target.wants/dummy-1.service to /etc/systemd/system/dummy-1.service. Created symlink from /etc/systemd/system/shutdown.target.wants/dummy-2.service to /etc/systemd/system/dummy-2.service. In another window I follow the journal which output I pasted after the commands I execute: # journalctl -f |grep dummy # systemctl start dummy-1 mei 14 19:58:20 joker systemd[1]: Started dummy one. # systemctl stop dummy-1 mei 14 19:58:25 joker systemd[1]: Stopping dummy one... mei 14 19:58:25 joker systemd[1]: Stopped dummy one. # systemctl start dummy-1 mei 14 19:58:30 joker systemd[1]: Starting dummy one... mei 14 19:58:30 joker systemd[1]: Started dummy one. # systemctl restart dummy-1 mei 14 19:58:34 joker systemd[1]: Stopping dummy one... mei 14 19:58:34 joker systemd[1]: Starting dummy one... mei 14 19:58:34 joker systemd[1]: Started dummy one. mei 14 19:58:34 joker systemd[1]: Starting dummy TWO... mei 14 19:58:34 joker systemd[1]: Started dummy TWO. # systemctl stop dummy-1 mei 14 19:58:39 joker systemd[1]: Stopping dummy one... mei 14 19:58:39 joker systemd[1]: Stopped dummy one. # systemctl restart dummy-1 mei 14 19:58:43 joker systemd[1]: Starting dummy one... mei 14 19:58:43 joker systemd[1]: Started dummy one. mei 14 19:58:43 joker systemd[1]: Starting dummy TWO... mei 14 19:58:43 joker systemd[1]: Started dummy TWO. As you can see, dummy-2 is not triggered by start or stop of dummy-1. However, it *is* triggered by restart of dummy-1 (no matter if dummy-1 has been started or not). Am I missing something here or did I find a bug? IMHO restart should be no different than stop ; start and it should certainly not trigger a unit which has a Requisite on that unit. I do not see it on openSUSE 13.2 with (heavily patched) systemd-210 so it appears to be a regression, unless there is some distro-specific patch. Reverse dependency for Requisite is Required-By and I have feeling it had already been discussed. Distro is Gentoo Linux Stable with kernel 3.18.13 and sys-apps/systemd-218-r3. The only systemd patch I see in the ebuild is 218-Dont-enable-audit-by-default.patch (journal/journald-audit.c) which doesn't seem too exciting. What is your message when you say Reverse dependency for Requisite is Required-By and I have feeling it had already been discussed.? What should I do now? Should I try systemd-219-r2, file a bug or simply wait until it's fixed? Evert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
Hi, 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. This can easily be reproduced using 2 dummy service units: # dummy-1.service: [Unit] Description=dummy one DefaultDependencies=false After=local-fs.target Before=basic.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/true ExecReload=/bin/true ExecStop=/bin/true [Install] WantedBy=sysinit.target multi-user.target Also=dummy-2.service # dummy-2.service [Unit] Description=dummy TWO DefaultDependencies=no After=dummy-1.service Before=shutdown.target Requisite=dummy-1.service [Service] Type=oneshot RemainAfterExit=no ExecStart=/bin/true [Install] WantedBy=shutdown.target # systemctl daemon-reload # systemctl enable dummy-1 Created symlink from /etc/systemd/system/sysinit.target.wants/dummy-1.service to /etc/systemd/system/dummy-1.service. Created symlink from /etc/systemd/system/multi-user.target.wants/dummy-1.service to /etc/systemd/system/dummy-1.service. Created symlink from /etc/systemd/system/shutdown.target.wants/dummy-2.service to /etc/systemd/system/dummy-2.service. In another window I follow the journal which output I pasted after the commands I execute: # journalctl -f |grep dummy # systemctl start dummy-1 mei 14 19:58:20 joker systemd[1]: Started dummy one. # systemctl stop dummy-1 mei 14 19:58:25 joker systemd[1]: Stopping dummy one... mei 14 19:58:25 joker systemd[1]: Stopped dummy one. # systemctl start dummy-1 mei 14 19:58:30 joker systemd[1]: Starting dummy one... mei 14 19:58:30 joker systemd[1]: Started dummy one. # systemctl restart dummy-1 mei 14 19:58:34 joker systemd[1]: Stopping dummy one... mei 14 19:58:34 joker systemd[1]: Starting dummy one... mei 14 19:58:34 joker systemd[1]: Started dummy one. mei 14 19:58:34 joker systemd[1]: Starting dummy TWO... mei 14 19:58:34 joker systemd[1]: Started dummy TWO. # systemctl stop dummy-1 mei 14 19:58:39 joker systemd[1]: Stopping dummy one... mei 14 19:58:39 joker systemd[1]: Stopped dummy one. # systemctl restart dummy-1 mei 14 19:58:43 joker systemd[1]: Starting dummy one... mei 14 19:58:43 joker systemd[1]: Started dummy one. mei 14 19:58:43 joker systemd[1]: Starting dummy TWO... mei 14 19:58:43 joker systemd[1]: Started dummy TWO. As you can see, dummy-2 is not triggered by start or stop of dummy-1. However, it *is* triggered by restart of dummy-1 (no matter if dummy-1 has been started or not). Am I missing something here or did I find a bug? IMHO restart should be no different than stop ; start and it should certainly not trigger a unit which has a Requisite on that unit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
В Thu, 14 May 2015 21:23:38 +0200 Evert evert.gen...@planet.nl пишет: Hi, 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. This can easily be reproduced using 2 dummy service units: # dummy-1.service: [Unit] Description=dummy one DefaultDependencies=false After=local-fs.target Before=basic.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/true ExecReload=/bin/true ExecStop=/bin/true [Install] WantedBy=sysinit.target multi-user.target Also=dummy-2.service # dummy-2.service [Unit] Description=dummy TWO DefaultDependencies=no After=dummy-1.service Before=shutdown.target Requisite=dummy-1.service [Service] Type=oneshot RemainAfterExit=no ExecStart=/bin/true [Install] WantedBy=shutdown.target # systemctl daemon-reload # systemctl enable dummy-1 Created symlink from /etc/systemd/system/sysinit.target.wants/dummy-1.service to /etc/systemd/system/dummy-1.service. Created symlink from /etc/systemd/system/multi-user.target.wants/dummy-1.service to /etc/systemd/system/dummy-1.service. Created symlink from /etc/systemd/system/shutdown.target.wants/dummy-2.service to /etc/systemd/system/dummy-2.service. In another window I follow the journal which output I pasted after the commands I execute: # journalctl -f |grep dummy # systemctl start dummy-1 mei 14 19:58:20 joker systemd[1]: Started dummy one. # systemctl stop dummy-1 mei 14 19:58:25 joker systemd[1]: Stopping dummy one... mei 14 19:58:25 joker systemd[1]: Stopped dummy one. # systemctl start dummy-1 mei 14 19:58:30 joker systemd[1]: Starting dummy one... mei 14 19:58:30 joker systemd[1]: Started dummy one. # systemctl restart dummy-1 mei 14 19:58:34 joker systemd[1]: Stopping dummy one... mei 14 19:58:34 joker systemd[1]: Starting dummy one... mei 14 19:58:34 joker systemd[1]: Started dummy one. mei 14 19:58:34 joker systemd[1]: Starting dummy TWO... mei 14 19:58:34 joker systemd[1]: Started dummy TWO. # systemctl stop dummy-1 mei 14 19:58:39 joker systemd[1]: Stopping dummy one... mei 14 19:58:39 joker systemd[1]: Stopped dummy one. # systemctl restart dummy-1 mei 14 19:58:43 joker systemd[1]: Starting dummy one... mei 14 19:58:43 joker systemd[1]: Started dummy one. mei 14 19:58:43 joker systemd[1]: Starting dummy TWO... mei 14 19:58:43 joker systemd[1]: Started dummy TWO. As you can see, dummy-2 is not triggered by start or stop of dummy-1. However, it *is* triggered by restart of dummy-1 (no matter if dummy-1 has been started or not). Am I missing something here or did I find a bug? IMHO restart should be no different than stop ; start and it should certainly not trigger a unit which has a Requisite on that unit. I do not see it on openSUSE 13.2 with (heavily patched) systemd-210 so it appears to be a regression, unless there is some distro-specific patch. Reverse dependency for Requisite is Required-By and I have feeling it had already been discussed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
