Bug 748512 - RFE: "systemctl --all" does not really list all
RFE: "systemctl --all" does not really list all
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Václav Pavlín
Fedora Extras Quality Assurance
:
: 812169 830589 (view as bug list)
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2011-10-24 12:21 EDT by Michal Schmidt
Modified: 2013-12-08 20:21 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-08 20:21:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michal Schmidt 2011-10-24 12:21:17 EDT
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
Comment 1 Lennart Poettering 2011-11-01 18:00:30 EDT
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?
Comment 2 foudfou 2012-01-13 13:50:04 EST
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.
Comment 3 Michal Schmidt 2012-04-13 07:26:13 EDT
*** Bug 812169 has been marked as a duplicate of this bug. ***
Comment 4 Elliott Forney 2012-04-24 19:20:31 EDT
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.
Comment 5 Michal Schmidt 2012-06-11 11:01:51 EDT
*** Bug 830589 has been marked as a duplicate of this bug. ***
Comment 6 foudfou 2012-06-15 09:02:53 EDT
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.
Comment 7 Jóhann B. Guðmundsson 2012-06-18 15:32:30 EDT
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...
Comment 8 Fedora End Of Life 2013-01-16 19:45:51 EST
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
Comment 9 Reartes Guillermo 2013-01-20 17:35:39 EST
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.
Comment 10 Václav Pavlín 2013-01-21 01:42:43 EST
Yes, I think it should be changed to F18 (moving there)
Comment 11 Elliott Forney 2013-03-25 23:05:24 EDT
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
Comment 12 Colin Guthrie 2013-03-26 05:25:21 EDT
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')
Comment 13 Elliott Forney 2013-03-26 14:33:57 EDT
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?
Comment 14 Colin Guthrie 2013-03-26 17:36:18 EDT
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.
Comment 15 Michal Schmidt 2013-03-27 06:53:53 EDT
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.
Comment 16 Sergio Monteiro Basto 2013-04-09 19:07:54 EDT
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
Comment 17 Colin Guthrie 2013-04-10 04:24:19 EDT
(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.
Comment 18 Harald Hoyer 2013-04-10 06:35:30 EDT
sent patch to ML clarifying "--all"

http://lists.freedesktop.org/archives/systemd-devel/2013-April/010296.html
Comment 19 Sergio Monteiro Basto 2013-04-10 09:08:43 EDT
(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
Comment 20 Colin Guthrie 2013-04-10 09:12:35 EDT
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.
Comment 21 Harald Hoyer 2013-04-17 05:09:04 EDT
commit 87698625aaf08ab2411a54a4ac9878acd4b46772
Comment 22 Zbigniew Jędrzejewski-Szmek 2013-12-08 20:21:02 EST
This has been fixed for a long time.

Note You need to log in before you can comment on or make changes to this bug.