Hide Forgot
Description of problem: Sometimes when firewalld is shut down, the rules are not getting removed completely Version-Release number of selected component (if applicable): RHEL 7.2 all updates How reproducible: Sometimes ~10% Steps to Reproduce: 1. Stop firewalld 2. iptables -L 3. Actual results: Sometimes some rules remain Expected results: No rules remain at any time Additional info:
What kind of rules are left over? Please add examples.
The default rules are sometimes left. Lev will probably paste the rules once he encounters the bug again.
Chain FWDO_public_allow (1 references) pkts bytes target prot opt in out source destination Chain FWDO_public_deny (1 references) pkts bytes target prot opt in out source destination Chain FWDO_public_log (1 references) pkts bytes target prot opt in out source destination Chain INPUT_ZONES (1 references) pkts bytes target prot opt in out source destination 28 2236 IN_public all -- ens3 * 0.0.0.0/0 0.0.0.0/0 [goto] 0 0 IN_public all -- + * 0.0.0.0/0 0.0.0.0/0 [goto] Chain INPUT_ZONES_SOURCE (1 references) pkts bytes target prot opt in out source destination Chain INPUT_direct (1 references) pkts bytes target prot opt in out source destination Chain IN_public (2 references) pkts bytes target prot opt in out source destination 28 2236 IN_public_log all -- * * 0.0.0.0/0 0.0.0.0/0 28 2236 IN_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0 28 2236 IN_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0 Chain IN_public_allow (1 references) pkts bytes target prot opt in out source destination 10 600 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW 0 0 ACCEPT udp -- * * 0.0.0.0/0 224.0.0.251 udp dpt:5353 ctstate NEW Chain IN_public_deny (1 references) pkts bytes target prot opt in out source destination Chain IN_public_log (1 references) pkts bytes target prot opt in out source destination Chain OUTPUT_direct (1 references) pkts bytes target prot opt in out source destination [root@lago_phase_1_suite_storage ~]# 0 0 FWDO_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FWDO_public_allow (1 references) pkts bytes target prot opt in out source destination Chain FWDO_public_deny (1 references) pkts bytes target prot opt in out source destination Chain FWDO_public_log (1 references) pkts bytes target prot opt in out source destination Chain INPUT_ZONES (1 references) pkts bytes target prot opt in out source destination 28 2236 IN_public all -- ens3 * 0.0.0.0/0 0.0.0.0/0 [goto] 0 0 IN_public all -- + * 0.0.0.0/0 0.0.0.0/0 [goto] Chain INPUT_ZONES_SOURCE (1 references) pkts bytes target prot opt in out source destination Chain INPUT_direct (1 references) pkts bytes target prot opt in out source destination Chain IN_public (2 references) pkts bytes target prot opt in out source destination 28 2236 IN_public_log all -- * * 0.0.0.0/0 0.0.0.0/0 28 2236 IN_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0 28 2236 IN_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0 Chain IN_public_allow (1 references) pkts bytes target prot opt in out source destination 10 600 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW 0 0 ACCEPT udp -- * * 0.0.0.0/0 224.0.0.251 udp dpt:5353 ctstate NEW Chain IN_public_deny (1 references) pkts bytes target prot opt in out source destination Chain IN_public_log (1 references) pkts bytes target prot opt in out source destination Chain OUTPUT_direct (1 references) pkts bytes target prot opt in out source destination # systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled) Active: inactive (dead) Aug 23 06:08:24 lago_phase_1_suite_storage systemd[1]: Starting firewalld - dynamic firewall daemon... Aug 23 06:08:24 lago_phase_1_suite_storage systemd[1]: Started firewalld - dynamic firewall daemon. Aug 23 06:09:22 lago_phase_1_suite_storage systemd[1]: Stopping firewalld - dynamic firewall daemon... Aug 23 06:09:22 lago_phase_1_suite_storage systemd[1]: Stopped firewalld - dynamic firewall daemon.
Are there any errors in the log? The CleanupOnExit setting in firewalld.conf is still set to yes?
If there are no errors and if CleanupOnExit is still set to yes, then please enable the debug mode in firewalld by setting "FIREWALLD_ARGS=--debug" in /etc/sysconfig/firewalld and attach the file /var/log/firewalld.log to this bug after starting and stopping firewalld and still having the left over rules.
(In reply to Thomas Woerner from comment #5) > If there are no errors and if CleanupOnExit is still set to yes, then please > enable the debug mode in firewalld by setting "FIREWALLD_ARGS=--debug" in > /etc/sysconfig/firewalld and attach the file /var/log/firewalld.log to this > bug after starting and stopping firewalld and still having the left over > rules. CleanupOnExit is set to yes, that is the default value. I modified the /etc/sysconfig/firewalld as asked and the only thing in the /var/log/firewalld is: 2016-08-24 08:11:54 WARNING: FedoraServer: INVALID_SERVICE: cockpit
This does not explain any left overs. It there would be an issue while stopping firewalld, then it would be reported. Do you see this also with the firewalld version in 7.3 beta? Could it be that something is accessing the firewalld D-Bus interface after it was stopped by systemd? This happended in the past sometimes if the dependency to the firewalld service was not there or not correct. Do you see a firewalld start before the system goes down?
(In reply to Thomas Woerner from comment #7) > This does not explain any left overs. It there would be an issue while > stopping firewalld, then it would be reported. Do you see this also with the > firewalld version in 7.3 beta? > > Could it be that something is accessing the firewalld D-Bus interface after > it was stopped by systemd? > > This happended in the past sometimes if the dependency to the firewalld > service was not there or not correct. > > Do you see a firewalld start before the system goes down? Haven't tested it with RHEL 7.3 beta. No idea if anything accesses the firewalld through D-Bus, however as we caught this in one of the Lago env., with the exactly same OS images being used for each run, and only in some cases we see the firewall issue, I doubt if that is the configuration issue. As we already pointed out this seemed to happen consistently, but not every time we created the env.
Lev, do we still see this? Let us reopen with fresh data if this still bothers us.
(In reply to Dan Kenigsberg from comment #9) > Lev, do we still see this? Let us reopen with fresh data if this still > bothers us. Haven't tested this recently, will re-open if it will re-occur.