Bug 988947

Summary: Enhancement: Do not show missing services mentioned in ordering as error
Product: [Fedora] Fedora Reporter: chris
Component: systemdAssignee: systemd-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: johannbg, lnykryn, msekleta, notting, plautrba, systemd-maint, vpavlin, zbyszek
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: 2013-09-12 19:51:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description chris 2013-07-26 18:37:31 UTC 
Description of problem:

As I am not a systemd expert I got confused why
systemctl -t service --all | grep error 
shows me services that are not installed on my system with status "error".
systemctl status always gives 
Loaded: error (Reason: No such file or directory)
for these services.
It turned out, the reason why they are shown as errors was simply that they were mentioned in Before or After conditions of other services.

Wouldn't it be better to just ignore it, if a service has an After=XY.service and there is no XY.service. Or at least do not call it an error if everything is working fine.
Comment 1 Jóhann B. Guðmundsson 2013-07-26 19:05:59 UTC 
(In reply to chris from comment #0)
> Description of problem:
> 
> As I am not a systemd expert I got confused why
> systemctl -t service --all | grep error 
> shows me services that are not installed on my system with status "error".
> systemctl status always gives 
> Loaded: error (Reason: No such file or directory)
> for these services.
> It turned out, the reason why they are shown as errors was simply that they
> were mentioned in Before or After conditions of other services.
> 
> Wouldn't it be better to just ignore it, if a service has an
> After=XY.service and there is no XY.service. Or at least do not call it an
> error if everything is working fine.

I would argue no since we need to identify incorrect orders in units

If we take this sample 

service A is order after service B so it has After=B.service 

If unit A works just fine without unit B ever existing on the installed system then that order is wrong and B.service should have Before=A.service in it's [Unit] section since it's the unit that's requires to be started before A if it's installed otherwise it will break unit A.
Comment 2 chris 2013-07-26 22:03:31 UTC 
But that would be true for all units which have no Requires or Wants for the services listed in Before or After.

And is it really impossible that you have two services which can run separately and only if they are both active A.service should be started before B.service.
In this case you would also have an error entry if you run the "wrong" service alone. 

Additional: it looks like even services listed under Conflicts produce these error entries.

For example:
My /lib/systemd/system/sendmail.service has the line 
Conflicts=postfix.service exim.service
Because of that both, postfix and exim get listed as services with an error
Reason: No such file or directory

My intuition is, it would be an error if they were there. Because then you might have a conflict (if enabled)
Comment 3 Lennart Poettering 2013-09-12 19:51:09 UTC 
They are ignore by default. However you explicitly asked them to be made visible by adding --all. 

There isn't really anything to fix here, this is intended behaviour.