This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes

Bug 680122

Summary: RFE: improve load error output in "systemctl status"
Product: [Fedora] Fedora Reporter: Horst H. von Brand <vonbrand>
Component: systemdAssignee: systemd-maint
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: henri, johannbg, lpoetter, maurizio.antillon, metherid, mschmidt, notting, plautrba, rtguille
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-12 22:40:59 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 784611, 799902    

Description Horst H. von Brand 2011-02-24 07:42:57 EST
Description of problem:
By mistake (and by getting service names wrong, and so on) I came across this:

# systemctl status sendmial.service
sendmial.service
          Loaded: error
          Active: inactive (dead)

This is scary/useless (sendmial.service certainly doesn't exist).

Version-Release number of selected component (if applicable):
systemd-18-1.fc16.x86_64

How reproducible:
Each time a non-existent service is called

Steps to Reproduce:
1. Ask for status of a non-existing service
2.
3.
  
Actual results:
See above

Expected results:
Error message to the effect that that doesn't exist

Additional info:
Comment 1 Lennart Poettering 2011-02-24 10:02:11 EST
Well, we do things this way since units might refer to non-existing services (for example to order themselves against them), and this is not an error. Think: apache wants to be started after mysql, but doesn't require it. If you only install apache, that's completely fine, but the dependency points to nowhere. And we don't consider that an error. Hence we allow instantiation of services with no config file.

On top of that it sometimes makes sense to show the status for a non-existing service: consider a service you started, and whose systemd unit file you then deleted -- but didn't stop. Now the configuration of that service is not available anymore, and it will show up as "Loaded: error", but there are still processes around. And we should show them. Or even when no process is around anymore you might want to know the exit code of the service when it last ran because it failed. I don't think we should ever suppress that information.

So I am not sure what we could do about this.
Comment 2 Bill Nottingham 2011-02-24 10:17:57 EST
Maybe propagate the error, such that it says:

  Loaded: error (No such file or directory)

Haven't looked to see how possible that is, though.
Comment 3 Lennart Poettering 2011-02-24 11:32:57 EST
Yupp, that's definitely something I want to do. And we store the error code actually for each service in process 1. The only reason this isn't passed on to the user is that I am not entirely sure how to do that best: include a dbus error pair (i.e name plus description) in the service data, or what precisely to do. And if I decide on tomsething it's hard to change that later on, since if its in the dbus API it's part of the API...
Comment 4 Fedora Admin XMLRPC Client 2011-10-20 12:24:55 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Reartes Guillermo 2011-12-03 17:35:23 EST
I come from 697185, today i revisited the systemctl human readable 
issue when using fake/incorrect unit names.

# systemctl status superman.service
superman.service
          Loaded: error (Reason: No such file or directory)
          Active: inactive (dead)

# systemctl -a | grep -i superman
superman.service          error  inactive dead          superman.service


Superman, Lex-Lutor, Batman and others are very obvious fake services. 
The problem is when you make a typo of an existing service and you don't
realize the typo. And i don't like the fact that something sticks to 
systemd, so i used a q&d script to query for fake services:

  #!/bin/bash
  COUNT=120000
  # bash while loop
  while [ $COUNT -gt 0 ]; do
  	systemctl status "ultra-fakeservice$COUNT.service"
  	let COUNT=COUNT-1
  done 

$ systemctl -a
[...TRUNCADED...]
dbus.service                                                         loaded active   running       D-Bus System Message Bus
dm-event.service                                                     loaded inactive dead          Device-mapper event daemon
emergency.service                                                    loaded inactive dead          Emergency Shell
exim.service                                                         error  inactive dead          exim.service
fakeservice55266.service                                             error  inactive dead          fakeservice55266.service
fakeservice55267.service                                             error  inactive dead          fakeservice55267.service
fakeservice55268.service                                             error  inactive dead          fakeservice55268.service
[...TRUNCADED...]

So, all these entries ar incorporated into the " ' -list- ' " until reboot. WOW
I run the script first with 65535 and after that with 12000, it was not able to complete the second run. After some 
finite number of systemctl executions, systemctl cannot be executed anymore. (ok, that is probably a security measure
or just pure luck)

$ systemctl -a | wc -l
95110

$ systemctl -a | wc -l
Failed to issue method call: Activation of org.freedesktop.systemd1 timed out

$ systemctl -a
Failed to issue method call: Activation of org.freedesktop.systemd1 timed out

# systemctl -a | wc -l
131068

# systemctl status the-matrix.service
Failed to issue method call: Argument list too long

It seems that not even root can increase the list of fake services.
It is scary that the script was run by a unprivileged user... now i think i must
reboot to restore to a normal systemd status. (nothing crashed, but some systemctl
commands do not complete...)


> Expected results:
> Error message to the effect that that doesn't exist
Not only does it does not exist, it also add itself to systemctl -a output, so a 'grep' can 'confirm'
that the service 'is' there.

* The output of 'systemctl status the-matrix.service' must be made more explicit. It must be clear
that the entered string IS NOT any service/socket/whatever part of systemd. It gladly accepts whatever
hast a .service appended at the end.

* The output of 'systemctl -a' must not grow as you search for non-existent services.

Is there any future plans for improving this specific systemctl behaviour?
  

systemd.x86_64          37-3.fc16   @updates
systemd-sysv.x86_64     37-3.fc16   @updates
systemd-units.x86_64    37-3.fc16   @updates
Comment 6 Reartes Guillermo 2011-12-03 17:53:09 EST
It seems that i found that these attachable fake-services has an effect. 
I am unable to reboot or poweroff.
(But i am able to start / stop services like sshd.service)

# init 6 

Messages:
 Dec  3 19:41:14 grimjow systemd-initctl[29292]: Failed to start unit: Argument list too long 
 Broadcast message from orasun@grimmjow.espada on pts/1 (Sat, 03 Dec 2011 19:41:14 -0300):
 The system is going down for reboot NOW!

And the time went on... no reboot.
# init 6

Messages:
 Dec  3 19:45:24 grimjow systemd-initctl[29292]: Failed to start unit: Argument list too long
 Broadcast message from orasun@grimmjow.espada on pts/1 (Sat, 03 Dec 2011 19:45:24 -0300):
 The system is going down for reboot NOW!

It does not reboot.
It seems that the script is able to put systemd into a special condition in which it does not 
accepts some commands. That includes 'init 6'

# init 0

Messages:
 Dec  3 19:49:15 grimjow systemd-initctl[29292]: Failed to start unit: Argument list too long
 Broadcast message from orasun@grimmjow.espada on pts/1 (Sat, 03 Dec 2011 19:49:15 -0300):
 The system is going down for power-off NOW!

Let's try something different:

# halt

Messages:
 Dec  3 19:49:55 grimjow systemd-initctl[29292]: Failed to start unit: Argument list too long
 Broadcast message from orasun@grimmjow.espada on pts/1 (Sat, 03 Dec 2011 19:49:55 -0300):
 The system is going down for system halt NOW!

Well, i did not expect 'halt' to fail, it is a true emergency command. (solaris is good at it: halt
and it just obeys, used in case of a fire o something critical that cannot be disobeyed).

Ok, do the ugly way (sync + sync + sync + power-off).
Comment 7 Michal Schmidt 2011-12-05 20:44:10 EST
(In reply to comment #5)
> * The output of 'systemctl status the-matrix.service' must be made more
> explicit.

I think "error (Reason: No such file or directory)" is explicit enough. It's definitely better than the bare "error" from the original bugreport.

> * The output of 'systemctl -a' must not grow as you search for non-existent
> services.

That is fixed now in upstream git:

http://cgit.freedesktop.org/systemd/commit/?id=9a46fc3b9014de1bf0ed1f3004a536b08a19ebb3

(In reply to comment #6)
> Well, i did not expect 'halt' to fail, it is a true emergency command.

A plain 'halt' is no emergency command. 'sync && poweroff -f' is.
Comment 8 Reartes Guillermo 2011-12-05 21:22:47 EST
> I think "error (Reason: No such file or directory)" is explicit enough. It's
> definitely better than the bare "error" from the original bugreport.

what about:
"no such unit, file or directory"

It is not that i consider "No such file or directory" as not explicit enough, certainly it is explicit enough. It is a perception issue, because it is like a fingerprint of "file not found". Adding "unit" seems fair and simpler.

# systemctl status superman.service
superman.service
          Loaded: error (Reason: No such unit, file or directory)
          Active: inactive (dead)



> That is fixed [...]

I am glad to know that it was fixed.
Comment 9 J├│hann B. Gu├░mundsson 2012-02-27 06:26:41 EST
Ping what's the current status on this?
Comment 10 Henri Salo 2012-03-04 04:46:28 EST
Requested CVE-identifier here: http://seclists.org/oss-sec/2012/q1/537
Comment 11 Lennart Poettering 2012-03-12 22:40:59 EDT
This is implemented in F17 for a while now. Closing.