Bug 12319

Summary: systemctl status can trigger actual administrative changes to the system, this conflicts with user expectations
Product: Mageia Reporter: Jonas Thiem <jonasthiem>
Component: RPM PackagesAssignee: Colin Guthrie <mageia>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: Normal    
Version: 3   
Target Milestone: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Source RPM: systemd-195-22.1.mga3.src.rpm CVE:
Status comment:

Description Jonas Thiem 2014-01-15 20:42:53 CET 
Description of problem:
systemctl status has actual effects on the system for some units (other than just displaying the status). In some cases they can be quite drastic, e.g. for shorewall in an active (exited) state it can cause sudden complete loss of internet connectivity. In less severe cases, it still looks like systemd is doing notably more than just displaying the status:

[root@localhost jonas]# systemctl status shorewall.service
shorewall.service - Shorewall IPv4 firewall
	  Loaded: loaded (/usr/lib/systemd/system/shorewall.service; disabled)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/shorewall.service

Jan 15 20:18:31 localhost shorewall[9121]: Processing /etc/shorewall/stop ...
Jan 15 20:18:31 localhost shorewall[9121]: iptables v1.4.17: Couldn't load t...y
Jan 15 20:18:31 localhost shorewall[9121]: Try `iptables -h' or 'iptables --....
Jan 15 20:18:31 localhost shorewall[9121]: iptables: No chain/target/match b....
Jan 15 20:18:31 localhost shorewall[9121]: iptables: No chain/target/match b....
Jan 15 20:18:31 localhost shorewall[9121]: Processing /etc/shorewall/tcclear ...
Jan 15 20:18:31 localhost shorewall[9121]: Running /sbin/iptables-restore...
Jan 15 20:18:31 localhost shorewall[9121]: Processing /etc/shorewall/stopped ...
Jan 15 20:18:32 localhost shorewall[9121]: done.
Jan 15 20:18:32 localhost systemd[1]: Stopped Shorewall IPv4 firewall.
[root@localhost jonas]#

Why is it messing around with iptables and tcclear? I just asked for the status, this is not really what I expected it to do.

In conclusion, systemctl status should either be renamed or it should stop messing around with the system. (or is there a good reason why it should do that for a simple status command?)

Version-Release number of selected component (if applicable):
systemd 195
mageia
+PAM +LIBWRAP +AUDIT -SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ

How reproducible:
100% for displaying things that suggest it is doing more things than it should do (as seen above), not sure how to trigger the specific bug of losing internet connectivity entirely of the shorewall unit.

Steps to Reproduce:
1. systemctl status shorewall.service
2. observe output


Reproducible: 

Steps to Reproduce:
Thierry Vignaud 2014-01-16 06:32:14 CET

Assignee: bugsquad => mageia

Comment 1 Colin Guthrie 2014-01-16 09:58:39 CET 
The lines shown in systemctl are the last 10 lines of *log* output. systemctl is not *doing* those things, it's *reporting* that they happened.

These commands were run by the service itself, not systemctl.

From the man systemctl page:

       status [NAME...|PID...]
           Show terse runtime status information about one or more units,
           followed by most recent log data from the journal. If no units are
           specified, show all units (subject to limitations specified with
           -t). If a PID is passed, show information about the unit the
           process belongs to.
...
       -n, --lines=
           When used with status, controls the number of journal lines to
           show, counting from the most recent ones. Takes a positive integer
           argument. Defaults to 10.

So if you don't like this, you can just use "systemctl status -n 0 shorewall"

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Comment 2 Jonas Thiem 2014-01-17 14:20:36 CET 
Ok. I assumed it was related because I lost internet connection right with the status command. It may have been caused by another command just before that though.

Thanks for explaining!