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:
Assignee: bugsquad => mageia
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 => RESOLVEDResolution: (none) => INVALID
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!