Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 549486 - sys-apps/systemd-218-r3 - Requisite implies TriggeredByRestartOf
Summary: sys-apps/systemd-218-r3 - Requisite implies TriggeredByRestartOf
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo systemd Team
URL: https://www.mail-archive.com/systemd-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-14 18:18 UTC by Evert
Modified: 2017-06-24 12:40 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge_--info.txt,5.86 KB, text/plain)
2015-05-14 18:18 UTC, Evert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Evert 2015-05-14 18:18:17 UTC
Created attachment 403262 [details]
emerge --info

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 and start.

This can easily be reproduced with 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 paste 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.
Comment 1 Mike Gilbert gentoo-dev 2015-05-14 18:34:38 UTC
This sounds like something you should discuss on the systemd-devel mailing list.