Hide Forgot
Description of problem: systemctl correctly reports error when trying to start or get status of unknown service: # systemctl start foobar.service Failed to issue method call: Unit foobar.service failed to load: No such file or directory. See system logs and 'systemctl status foobar.service' for details. # systemctl status foobar.service foobar.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) # echo $? 3 However, it returns success when trying to stop it. # systemctl stop foobar.service # echo $? 0 Version-Release number of selected component (if applicable): systemd-37-2.fc16.x86_64 How reproducible: Steps to Reproduce: 1. systemctl stop foobar.service 2. Check error message and return status 3. Actual results: Returns success. Expected results: Reports error (and an error message)
This seems to be intentional since this upstream commit, but the rationale escapes me: http://cgit.freedesktop.org/systemd/commit/?id=3dda9fc3a738241e42df43dbebf9e479e5ad1da8 manager: always allow stopping of units that failed to load
Me neither. The old SystemV returned errors in this case: # service foobar stop foobar: unrecognized service # echo $? 1
There might be services running which failed to load, due to configuration reloads. i.e. first you boot a machine with a service file A.service, and you start it. Then you delete the service file A.service, and do "systemctl daemon-reload". At this point the service is still running, and will be introspectable in systemd, but it will appear as failed to load. In such a case we must make sure you can still shut it down cleanly. This is the reason btw, why the load state and the unit state are distinct. Because "activate" and "inactive" units can exist in both "loaded" and "failed" load states, they are mostly independent. Basically the only interaction between the two states is that you cannot start a service that failed to load, even though you can stop it.