Bug 1155178

Created attachment 948967 [details]
SOS Report of system when firewalld is stopped

SOS Report of system when firewalld is stopped, the output of 

systemctl list-units --all does not contain firewalld

Created attachment 948968 [details]
SOS Report of system when firewalld is started

SOS Report of system when firewalld is stopped, the output of 

systemctl list-units --all does contain firewalld

This is expected, we don't show unloadad unit in the output for performance reasons. We don't hold them in memory and traversing through filesystem is too slow.

From the man page:

"-a, --all
           When listing units, show all loaded units, regardless of their state, including inactive units. When showing unit/job/manager properties, show all properties regardless whether they are set or not."

How does one define the word "loaded" in the context of systemd?

The output of the following commands is inconsistent with your definition of expected behavior?


===============================================================
systemctl disable cups.service
rm '/etc/systemd/system/multi-user.target.wants/cups.path'
rm '/etc/systemd/system/sockets.target.wants/cups.socket'
rm '/etc/systemd/system/printer.target.wants/cups.service'
[root@localhost ~]# systemctl status cups.service
cups.service - CUPS Printing Service
   Loaded: loaded (/usr/lib/systemd/system/cups.service; disabled)
   Active: active (running) since Tue 2014-10-21 09:51:42 EDT; 4h 19min ago
 Main PID: 4168 (cupsd)
   CGroup: /system.slice/cups.service
           └─4168 /usr/sbin/cupsd -f

Oct 21 09:51:42 localhost.localdomain systemd[1]: Starting CUPS Printing Service...
Oct 21 09:51:42 localhost.localdomain systemd[1]: Started CUPS Printing Service.
===============================================================


Notice the line: 

     "Loaded: loaded (/usr/lib/systemd/system/cups.service; disabled)"

This implies that if the unit is on disk and read by systemd it is "loaded", therefore the two commands

1. systemctl status cups.service
2. systemctl --all list-units | grep cups

are inconsistent.

Furthermore, the output of the following command makes it even more inconsistent:

    systemctl list-units

    ...
    111 loaded units listed. Pass --all to see loaded but inactive units, too.
    To show all installed unit files use 'systemctl list-unit-files'.
    ...

This implies that the command systemctl list-unit-files must be ran to actually get what is on disk. So the question is, what does loaded mean?

If loaded means on disk, then somethings need to change. If loaded means on disk but not what? Enabled or disabled, it is listed in the status command?  The most rational thing to do would be to get rid of "systemctl list-unit-files" and collapse it into "systemctl list-units" which should show everything that is on disk (aka. loaded)

Hope that helps :-)

Well 'loaded' means that unit, an abstraction of system resource, is known to systemd and systemd is tracking its state. But "known to systemd" doesn't necessarily imply that there is a unit file for such unit on disk.

Simply put, if you are interested in services you can start/enable/disable then you should use output of systemctl list-unit-files. If you want to introspect current system state you should consult output of systemctl list-units.

We can't merge list-units and list-unit-files and administrators *must* be aware about both options. Frankly, I think we do reasonably good job here because output of systemctl list-units points to the latter and even mentions --all option.

(In reply to Michal Sekletar from comment #6)
> Well 'loaded' means that unit, an abstraction of system resource, is known
> to systemd and systemd is tracking its state. But "known to systemd" doesn't
> necessarily imply that there is a unit file for such unit on disk.
> 
> Simply put, if you are interested in services you can start/enable/disable
> then you should use output of systemctl list-unit-files. If you want to
> introspect current system state you should consult output of systemctl
> list-units.
> 
> We can't merge list-units and list-unit-files and administrators *must* be
> aware about both options. Frankly, I think we do reasonably good job here
> because output of systemctl list-units points to the latter and even
> mentions --all option.

First, I do think you do a good job of pushing people to the list-unit-files. I love the output.

That said, there may be some other reasons that the two commands cannot be merged, but the reason above does not make logical sense. I understand that being on disk is a sufficient condition to being "Known to systemd", but it is not a necessary condition of being a unit. Stated another way, I understand that not all units are files. The question is are all files units?

Wouldn't being on disk, generally, not just for services, be enough to be "tracked by systemd?" If that is not a sufficient condition, then the following command should be broken right, because it is "not tracking"

systemctl disable cups.service
rm '/etc/systemd/system/multi-user.target.wants/cups.path'
rm '/etc/systemd/system/sockets.target.wants/cups.socket'
rm '/etc/systemd/system/printer.target.wants/cups.service'

[root@localhost ~]# systemctl status cups.service
cups.service - CUPS Printing Service
   Loaded: loaded (/usr/lib/systemd/system/cups.service; disabled)
   Active: active (running) since Tue 2014-10-21 09:51:42 EDT; 4h 19min ago
 Main PID: 4168 (cupsd)
   CGroup: /system.slice/cups.service
           └─4168 /usr/sbin/cupsd -f

So *why* would "status" return anything other than unknown or nothing if systemd is NOT tracking it?

Confused???

First of all unit files and units are two distinct kinds of objects. That means you can't really think in terms of set algebra when reasoning about the two. I am sorry I should have made this clear earlier.

Anyway, to comment on example given. I fail to see where is the problem. Unit cups.service exists and systemd is tracking processes which belong to that service. 
Unit file cups.service is initially in enabled state (most likely because of that there is a cups.service unit in the first place) and by calling disable you change the state to disabled.
That of course, doesn't affect unit in any way. Unit stays active and loaded. It doesn't get inactive or unloaded because of disable right now. Perhaps on next boot if there is no other enabled service which requires cups to be running, then cups.service unit file will not be processed hence no cups.service unit will exist, thus will not show up in systemctl list-units.

Hope that makes sense.

Per your comment: "...and by calling disable you change the state to disabled.
That of course, doesn't affect unit in any way..."

This is untrue, the unit is indeed affected. Look at the output from the following commands:

Start with firewalld stopped and disabled
================================================================
[root@localhost ~]# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled)
   Active: inactive (dead)

Enable, but do not start, it is still not a unit
================================================================
[root@localhost ~]# systemctl enable firewalld
ln -s '/usr/lib/systemd/system/firewalld.service' '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'
ln -s '/usr/lib/systemd/system/firewalld.service' '/etc/systemd/system/basic.target.wants/firewalld.service'
[root@localhost ~]# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: inactive (dead)
[root@localhost ~]# systemctl list-units | grep firewall
[root@localhost ~]# 

Enabled, now start, now firewalld becomes a unit
================================================================
[root@localhost ~]# systemctl list-units | grep firewall
firewalld.service                                                                         loaded active running   firewalld - dynamic firewall daemon

Enabled, now stop, now firewalld is no longer a unit
================================================================
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# systemctl list-units | grep firewall
[root@localhost ~]# 


================================================================

It is my understanding of units, that this should still be a unit, because it systemd tracking status of and has loaded the unit file????  If that were not true, then the following command should not work. And even if it should work, it should not say "loaded" because loaded "...means that unit, an abstraction of system resource, is known to systemd and systemd is tracking its state...:


[root@localhost ~]# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: inactive (dead) since Mon 2014-10-27 14:30:07 EDT; 2min 40s ago
  Process: 9952 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=0/SUCCESS)
 Main PID: 9952 (code=exited, status=0/SUCCESS)

Oct 27 14:29:16 localhost.localdomain systemd[1]: Started firewalld - dynamic firewall daemon.
Oct 27 14:30:06 localhost.localdomain systemd[1]: Stopping firewalld - dynamic firewall daemon...
Oct 27 14:30:07 localhost.localdomain systemd[1]: Stopped firewalld - dynamic firewall daemon.


Do you see how this is a problem? It's a paradox? The status command should say unloaded if list-units doesn't show it. Then it would be intuitive to use list-unit-files....

I hope this is clear now???

I don't think that status should show unloaded or so because unit still exits. State of unit is loaded but inactive. That is why it didn't show up in output of list-units. To see all units, including inactive ones, you have to pass --all option to list-units. Does that not work for you?

Exactly, I made a mistake in comment 9, it should have included the --all option. That's what I had tried to show in comment 5.

==================================================================
[root@rhel7 system]# systemctl stop firewalld.service
[ro[root@rhel7 system]# systemctl --all list-units | grep firewallot@rhel7 system]# systemctl disable firewalld.service
[root@rhel7 system]# systemctl --all list-units | grep firewall
==================================================================
There is no output from the systemctl --all list-units | grep firewall

But status still shows output with the word "loaded"
==================================================================
[root@rhel7 system]# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled)
   Active: inactive (dead)

Oct 27 23:37:05 rhel7.crunchtools.com firewalld[519]: 2014-10-27 23:37:05 ERROR: '/sbin/iptables -D INPUT_ZONES 1 -t filter -i veth3547 -g IN_pu... command
                                                      
                                                      Try `iptables -h' or 'iptables --help' for more information....
Oct 27 23:37:05 rhel7.crunchtools.com firewalld[519]: 2014-10-27 23:37:05 ERROR: COMMAND_FAILED: '/sbin/ip6tables -I FORWARD_OUT_ZONES 1 -t filt... option?
Oct 27 23:41:26 rhel7.crunchtools.com firewalld[519]: 2014-10-27 23:41:26 ERROR: '/sbin/iptables -I FORWARD_OUT_ZONES 1 -t filter -o vetha6d2 -g... option?
Oct 27 23:41:26 rhel7.crunchtools.com firewalld[519]: 2014-10-27 23:41:26 ERROR: '/sbin/iptables -D INPUT_ZONES 1 -t filter -i vetha6d2 -g IN_pu... command
                                                      
                                                      Try `iptables -h' or 'iptables --help' for more information....
Oct 27 23:41:26 rhel7.crunchtools.com firewalld[519]: 2014-10-27 23:41:26 ERROR: COMMAND_FAILED: '/sbin/iptables -I FORWARD_OUT_ZONES 1 -t filte... option?
Oct 27 23:45:08 rhel7.crunchtools.com firewalld[519]: 2014-10-27 23:45:08 ERROR: '/sbin/iptables -I FORWARD_OUT_ZONES 1 -t filter -o veth266e -g... option?
Oct 27 23:45:08 rhel7.crunchtools.com firewalld[519]: 2014-10-27 23:45:08 ERROR: '/sbin/iptables -D INPUT_ZONES 1 -t filter -i veth266e -g IN_pu... command
                                                      
                                                      Try `iptables -h' or 'iptables --help' for more information....
Oct 27 23:45:08 rhel7.crunchtools.com firewalld[519]: 2014-10-27 23:45:08 ERROR: COMMAND_FAILED: '/sbin/iptables -I FORWARD_OUT_ZONES 1 -t filte... option?
Oct 28 08:07:33 rhel7.crunchtools.com systemd[1]: Stopping firewalld - dynamic firewall daemon...
Oct 28 08:07:33 rhel7.crunchtools.com systemd[1]: Stopped firewalld - dynamic firewall daemon.
Hint: Some lines were ellipsized, use -l to show in full.
==================================================================

If I enable it again, it comes back
==================================================================
[root@rhel7 system]# systemctl enable firewalld
ln -s '/usr/lib/systemd/system/firewalld.service' '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'
ln -s '/usr/lib/systemd/system/firewalld.service' '/etc/systemd/system/basic.target.wants/firewalld.service'
[root@rhel7 system]# systemctl --all list-units | grep firewall
firewalld.service                                                                                              loaded inactive dead      firewalld - dynamic firewall daemon
==================================================================

The output of "status" always shows loaded, while the output of "list-units --all" does not. Basically, it seems like "list-units --all" should show the unit even if disabled and off, because systemd is still aware of it and tracking it. It will shut it down in an isolation of target that does not include it, so it can definitely "manage" it if it's on disk. I think active and loaded are being confounded.

Best Regards
Scott M