Description of problem: "systemctl --all" only lists the units that have already been loaded. If systemd had no reason to load a unit, the unit won't be shown. This is inconvenient. People expect '--all' to mean really all units they can possibly manage with systemctl. systemctl's bash-completion also relies on parsing the output of "systemctl --all". Version-Release number of selected component (if applicable): systemd-37-2.fc16 How reproducible: always Steps to Reproduce: 1. Have bash-completion installed. 2. yum install httpd 3. systemctl start htt<TAB> 4. systemctl --all --full | grep httpd Actual results: No completion is offered in step 3. Nothing is printed in step 4. Expected results: httpd.service (and possibly others) should be offered in step 3 and printed in step 4. Additional info: Noticed by Radek Hladik in a Czech forum: http://www.abclinuxu.cz/poradna/linux/show/346943
i don't think it would be wise to load all thinkable units in --all. Especially since there is in infinite amount of them due to device units or instantiated services. (And to get the list of unit files from disk is sloooow) I think the right thing to do here is get people to use "systemctl list-unit-files" which avoids this confusion and only lists unit files and makes that clear in the name. (Note that "systemctl --all" is just short for "systemctl list-units --all"). Or how exactly would you think this should look like?
I find list-unit-files not very intuitive. I would rather see things like this: list-units --all: all possible units list-units --enabled: --all restricted to enabled units list-units --disabled: --all restricted to disabled units list-units --active: --all restricted to active units list-units --inactive: --all restricted to inactive units these should be combinable, like: list-units --active --disabled. At the moment list-units defaults to --active --inactive --enabled.
*** Bug 812169 has been marked as a duplicate of this bug. ***
Hmm, I understand that it's not possible to list all devices, et cetra. With the larger scope of systemd (as opposed to upstart) this had not occurred to me. I suppose list-unit-files solves the problem for me at the moment but allow me to describe the use-case that I am after: Say that I desire to enable a service (or whatever) in systemd. Before I can do this I need to know what it is called and whether or not it exists on the system. My first instinct is to run "systemctl -a | grep name" to find it; however, this doesn't currently work if the unit is inactive. In short, what I am after is an intuitive way to find things in systemd, even if they are not currently active. Also, I might mention that there is no doubt in my mind that the description in the current man page is incorrect: "When listing units, show all units, regardless of their state, including inactive units. When showing unit/job/manager properties, show all properties regardless whether they are set or not." In fact, "systemctl --all" does not show all units regardless of their state.
*** Bug 830589 has been marked as a duplicate of this bug. ***
Another problem is when you want to list inactive units, for example to find out which ones you can start (that's what the bash completion script for systemctl tries to do). You then need 2 commands: systemdctl list-units --all | grep ' inactive ' systemctl list-unit-files | grep ' disabled' As a user, I do not want to deal with implementation aspects, I want to deal with units (all of them). Why would the user have to issue a list-unit-files to find out which units he can start, and beforhand, how would he even know he'd have to do that ? Even the --help is not correct: there is no 'start' command for Unit File Commands. But obviously, unit-files *can* be started without being enabled. Also, there is currently no way to list all possible units in one command. I suggest Unit Commands and Unit File Commands are merged together. Then options like --files, --transient, --generated could be of interest for the list-units command.
From usability perspective it probably would be best to have command like systemctl show active/inctive/enable/disable units/targets instead of forcing users to use pipe and grep to find this stuff out...
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
In F18: Comment #4: * "When listing units, show all units, regardless of their state, including inactive units. When showing unit/job/manager properties, show all properties regardless whether they are set or not." The man page does still says the same. Comment #6 seems to still apply. # yum install httpd These commands will not find anything: # systemctl --all | grep -i httpd # systemctl list-units --all | grep ' inactive ' | grep -i http This command does find something: # systemctl list-unit-files | grep ' disabled' |grep -i http httpd.service disabled While inconvenient (compared to 'chkconfig --list|grep -i http') it seems to be the way to do it. What is the status of this bug-report? Should its version be changed to 18 or closed in some form? Cheers.
Yes, I think it should be changed to F18 (moving there)
I am still having a seriously difficult time trying to understand what command(s) to use to locate a service. Consider all of the inconsistencies in the following example: # iptables is disabled and inactive on my system and has a unit file. # It does show up with all of the following three systemctl commands: $ systemctl --all | grep iptables iptables.service loaded inactive dead IPv4 firewall with iptables $ systemctl list-unit-files | grep iptables iptables.service disabled $ systemctl --all list-units | grep iptables iptables.service loaded inactive dead IPv4 firewall with iptables $ chkconfig --list 2>&1 | grep iptables # ypbind is disabled and inactive on my system and has a unit file. # It ONLY shows up with list-unit-files!!! # Why is this any different than iptables? # Why does this not show up with --all? $ systemctl --all | grep ypbind $ systemctl list-unit-files | grep ypbind ypbind.service disabled $ systemctl --all list-units | grep ypbind $ chkconfig --list 2>&1 | grep iptables # vnstat is disabled and inactive on my system and still # has an /etc/init.d startup script. # It DOES show up with --all and not with list-unit-files but # it does show up with list-units and chkconfig. # Why does this non-native service show up with --all and # list-units but the native ypbind did not? $ systemctl --all | grep vnstat vnstat.service loaded inactive dead LSB: lightweight network traffic monitor $ systemctl list-unit-files | grep vnstat $ systemctl --all list-units | grep vnstat vnstat.service loaded inactive dead LSB: lightweight network traffic monitor $ chkconfig --list 2>&1 | grep vnstat vnstat 0:off 1:off 2:off 3:off 4:off 5:off 6:off
If I understand correctly your first two examples (without clouding things with the latter ones), the iptables and ypbind setups are very similar (both native systemd units, no sysvinit scripts) correct? The reason iptables shows up under systemctl --all output is simply due to timing. Sometimes it will show up, sometimes not. It really depends on when the garbage collection has last run. I agree this is inconsistent, but the rule is that systemctl --all will not necessarily show disabled units. The documentation is fairly clear on this but I still agree it's non-deterministic and feels inconsistent. Regarding the vnstat issue, I'm not sure why it's loaded inactive dead state. I would have thought it should be disabled. Certainly on my systemd 195 system it does not show up as "loaded inactive dead" unless I have started it and stopped it again manually: [colin@jimmy ~]$ systemctl --all | grep vnstat [colin@jimmy ~]$ systemctl list-unit-files | grep vnstat [colin@jimmy ~]$ systemctl --all list-units | grep vnstat [colin@jimmy ~]$ chkconfig --list 2>&1 | grep vnstat vnstat 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off [colin@jimmy ~]$ sudo systemctl start vnstat.service [colin@jimmy ~]$ sudo systemctl stop vnstat.service [colin@jimmy ~]$ systemctl --all | grep vnstat vnstat.service loaded inactive dead LSB: lightweight network traffic monitor Note as stated previously this is a slightly older systemd than is available in Fedora 18 so it could be a regression or it could be a result of you running specific commands on the services before capturing the above output (e.g. running systemctl status/start/stop etc.) will load the unit and cause changes. Basically if you want to see the state of the files on disk, use list-unit-files if you want to know the state of the units systemd is currently tracking use list-units. Unfortunately, sysvinit scripts still need to be looked at via chkconfig it seems (tho' it was my understanding that the generators present in systemd 197 solved this problem and converted them to real units that would show up in list-unit-files... could be wrong there tho')
Yes, both iptables and ypbind are native systemd units and both are disabled. I see. I wasn't aware of this garbage collection before now. This may be part of the reason for my confusion. Just out of curiosity, when does this collection run? My system has an uptime of 28 days and I have tried running daemon-reload and I still see this inconsistency. Thank you for your insight into my confusion with the vnstat service, it no longer appears, I may have started and stopped it. So, I understand that systemd currently does not show disabled units with --all (that is what this bug report is about) but I think there are still a couple of issues here: 1. I disagree that the documentation is clear on this. As stated in comment #4, the man page states that "--all" will show everything regardless of state, et cetra. The "list-units" section of the man page simply states "List known units." Where does the documentation explain that disabled units are not shown, even with --all? Where does the documentation explain how to list disabled units? 2. Why does --all not list disabled units? In comment #1, Lennart explained that there could be an infinite number of possible entries (e.g. devices) and that fetching unit files from disk is "slow." I would make the argument that I wouldn't expect non-existent devices to be listed any more than I would expect systemctl to list every service that could "possibly" exist. I would, however, expect --all to list disabled services just as I would expect it to list, say, an unmounted disk. After all, they do exist, they are just not running. Perhaps others won't buy this but it is worth considering. 3. As far as I can tell, the only way to currently search all available units is to first run "systemctl list-unit-files | grep regex' and then to check sysv init scripts with chkconfig or checking /etc/init.d. Is this correct? Would it be possible/logical to list sysv init scripts with list-unit-files? Since systemd is managing these services, perhaps they should be listed?
Yeah perhaps "clear" was the wrong expression ;) It could certainly be clearer. IMO it would be clearer if --all simply ignored disabled plugins even if they existed. This would at least make it's output deterministic and separate the user from the internal details of the garbage collection logic. Or, of course, if it actually did display the disabled units then that would be OK too. But one way or the other I think it should be more consistent (and I understand Lennart's point about .device units cluttering things up here). I don't know exactly when it's run BTW, just the principle that it exists. I suspect a daemon-reload just serialises and unserialises the state verbatim so no GC is run. As for your point 3, yes, this is my understanding as of systemd 195 (the need to combine both list-unit-files and chkconfig). The way sysvinit compatibility is handled changed after this version so things may actually behave a little differently now (with list-unit-files perhaps being sufficient?), but I'm not personally tracking that version yet, so I've not looked too deeply, sorry.
This topic was briefly discussed last month on the systemd hackfest in Brno. We agreed that the current behaviour of "systemctl --all" is confusing for users. In the end Lennart was not opposed to the idea of changing it, so that it would print even available units that are not currently loaded, even if it would be a (relatively) slow operation. At this point it would be great if someone came up with patches.
To show all installed unit files use 'systemctl list-unit-files'. this sentence should be in man page and systemctl in description of list-unit-files
(In reply to comment #16) > To show all installed unit files use 'systemctl list-unit-files'. > > this sentence should be in man page and systemctl in description of > list-unit-files It currently says: list-unit-files List installed unit files.
sent patch to ML clarifying "--all" http://lists.freedesktop.org/archives/systemd-devel/2013-April/010296.html
(In reply to comment #17) > (In reply to comment #16) > > To show all installed unit files use 'systemctl list-unit-files'. > > > > this sentence should be in man page and systemctl in description of > > list-unit-files > > It currently says: > > list-unit-files > List installed unit files. should be: list-unit-files To show all installed unit files don't know if Harald Hoyer patch do this
It does not, but it's also better as it is currently as with that change the grammatical style is not consistent. Perhaps the addition of the word "all" would be OK, but not the "To show..." prefix.
commit 87698625aaf08ab2411a54a4ac9878acd4b46772
This has been fixed for a long time.