Description of problem: In some cases, the systemd kill command returns zero exitcode although it has no real effect. This happens usually with services that are not typical daemons. Example services: ebtables, iptables, arptables_jf. In fact there is nothing to kill in these cases. But I think the kill command should either stop given service and return zero exitcode in case of success, or should do nothing and return some non-zero exitcode. It would be also nice if the kill command provided at least some feedback about what it did. Version-Release number of selected component (if applicable): systemd-44-4.fc17.x86_64
Hm, yes, it seems reasonable to report "No process found" or similar when there's nothing to kill.
Reproduced with systemd-204-8.fc19.x86_64. Moving to Rawhide.
What exactly is your reproducer?
(In reply to Jan Synacek from comment #3) > What exactly is your reproducer? Example: fc20 x86_64 # systemctl status ebtables.service ebtables.service - Ethernet Bridge Filtering tables Loaded: loaded (/usr/lib/systemd/system/ebtables.service; disabled) Active: inactive (dead) May 13 14:07:45 dhcp-24-165.brq.redhat.com systemd[1]: Stopped Ethernet Bridge Filtering tables. fc20 x86_64 # systemctl kill ebtables.service fc20 x86_64 # # here I'd expect message like "nothing was killed in fact, dude".
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Implemented in https://github.com/systemd/systemd/pull/1311. It is now possible to use 'systemctl --fail kill ...' to get an error when there was nothing to kill.