Red Hat Bugzilla – Full Text Bug Listing
|Summary:||RFE: improve load error output in "systemctl status"|
|Product:||[Fedora] Fedora||Reporter:||Horst H. von Brand <vonbrand>|
|Status:||CLOSED NEXTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||henri, johannbg, lpoetter, maurizio.antillon, metherid, mschmidt, notting, plautrba, rtguille|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-03-12 22:40:59 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|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: Failed to start unit: Argument list too long Broadcast message from firstname.lastname@example.org 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: Failed to start unit: Argument list too long Broadcast message from email@example.com 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: Failed to start unit: Argument list too long Broadcast message from firstname.lastname@example.org 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: Failed to start unit: Argument list too long Broadcast message from email@example.com 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.