Bug 748435

Summary: systemctl stop ends successfully for unknown service
Product: [Fedora] Fedora Reporter: Martin Kosek <mkosek>
Component: systemdAssignee: systemd-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: johannbg, lpoetter, metherid, mschmidt, notting, plautrba, systemd-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-01 22:06:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Martin Kosek 2011-10-24 12:56:20 UTC 
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)
Comment 1 Michal Schmidt 2011-10-24 13:20:22 UTC 
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
Comment 2 Martin Kosek 2011-10-24 13:49:19 UTC 
Me neither. The old SystemV returned errors in this case:

# service foobar stop
foobar: unrecognized service
# echo $?
1
Comment 3 Lennart Poettering 2011-11-01 22:06:25 UTC 
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.