It seems that the recursive module unloading in iptables.service at some point hits modules which are used by ip6tables as well. My guess here is a race condition between that unloading and the already starting ip6tables.service which makes the kernel load required modules but that fails because depending modules are being unloaded at the same time. That would explain the "unknown symbol" messages logged when restarting fails at least.

I discussed possible fixes with Eric, and we concluded that either recursive module unloading should be limited to modules not in use by the other IP family or the two services should be excluded from being restarted in parallel by systemd.

Limiting recursive module unloading turned out to be not feasible since it's hard to detect whether a module is used by both families, hence I went for the other alternative - it is possible to establish serialization by adding After/Before variables to service definitions.

Note that although this will prevent the race condition for a user calling 'systemctl restart iptables ip6tables', we still need to add --wait option to iptables calls in both services' init files since it might still happen that another process/user calls plain iptables and therefore causes the lock issue.

*** Bug 1486871 has been marked as a duplicate of this bug. ***

Created attachment 1341179 [details]
Proposed fix for issues

After 7.4.2 update there is still an error in log:

[/usr/lib/systemd/system/ip6tables.service:3] Failed to add dependency on syslog.target,iptables.service, ignoring: Invalid argument

Attached patch fixes it and also fixes wrong patching of iptables.service which happens to actual source file.

I applied the manual fix of changing teh comma to a space, and then did a relabel of the parent file

this removed the error

BUT

when using the second test, 

I now get SVG errors:

[root@router ~]# restorecon -Rv /usr/lib/systemd/system/ip6tables.service
[root@router ~]# systemctl daemon-reload
[root@router ~]# systemctl restart iptables ip6tables
[root@router ~]#

the last yields (newly)
]
Feb 13 13:25:49 router dbus[794]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper)
Feb 13 13:25:49 router systemd: Started IPv6 firewall with ip6tables.
Feb 13 13:25:50 router dbus-daemon: dbus[794]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Feb 13 13:25:50 router dbus[794]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Feb 13 13:25:50 router kernel: Ebtables v2.0 unregistered
Feb 13 13:25:50 router kernel: [ 8910.020673] Ebtables v2.0 unregistered
Feb 13 13:25:50 router libvirtd: 2018-02-13 18:25:50.699+0000: 1428: info : libvirt version: 3.2.0, package: 14.el7_4.7 (CentOS BuildSystem <http://bugs.centos.org>, 2018-01-04-19:31:34, c1bm.rdu2.centos.org)
Feb 13 13:25:50 router libvirtd: 2018-02-13 18:25:50.699+0000: 1428: info : hostname: router.owlriver.net
Feb 13 13:25:50 router libvirtd: 2018-02-13 18:25:50.699+0000: 1428: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files

**** from something down in libvirt it seems -- noted here, but proceeding

Feb 13 13:25:50 router systemd: Stopped firewalld - dynamic firewall daemon.
Feb 13 13:25:53 router setroubleshoot: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/lockd.conf. For complete SELinux messages run: sealert -l 8f8426fb-329d-4786-872c-69ef36e9020d

Feb 13 13:25:53 router python: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/lockd.conf.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that grep should be allowed read access on the lockd.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'grep' --raw | audit2allow -M my-grep#012# semodule -i my-grep.pp#012

Feb 13 13:25:53 router setroubleshoot: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/mlx4.conf. For complete SELinux messages run: sealert -l 8f8426fb-329d-4786-872c-69ef36e9020d

Feb 13 13:25:53 router python: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/mlx4.conf.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that grep should be allowed read access on the mlx4.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'grep' --raw | audit2allow -M my-grep#012# semodule -i my-grep.pp#012

Feb 13 13:25:53 router setroubleshoot: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/truescale.conf. For complete SELinux messages run: sealert -l 8f8426fb-329d-4786-872c-69ef36e9020d

Feb 13 13:25:53 router python: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/truescale.conf.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that grep should be allowed read access on the truescale.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'grep' --raw | audit2allow -M my-grep#012# semodule -i my-grep.pp#012

Feb 13 13:25:53 router setroubleshoot: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/tuned.conf. For complete SELinux messages run: sealert -l 8f8426fb-329d-4786-872c-69ef36e9020d
Feb 13 13:25:53 router python: SELinux is preventing /usr/bin/grep from read access on the file /etc/modprobe.d/tuned.conf.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that grep should be allowed read access on the tuned.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'grep' --raw | audit2allow -M my-grep#012# semodule -i my-grep.pp#012



The 'owning packages' for those files are:

[root@router ~]# rpm -qf /etc/modprobe.d/lockd.conf /etc/modprobe.d/mlx4.conf /etc/modprobe.d/truescale.conf /etc/modprobe.d/tuned.conf 
nfs-utils-1.3.0-0.48.el7_4.1.x86_64
rdma-core-13-7.el7.x86_64
rdma-core-13-7.el7.x86_64
tuned-2.8.0-5.el7_4.2.noarch
[root@router ~]# 

each parent is unaltered:

[root@router ~]# rpm -V nfs-utils rdma-core tuned
[root@router ~]# 

I suggest that your testing be expanded to:
   . install the three packages
   . run: systemctl daemon-reload
(expected to run without execception)
   . systemctl restart iptables ip6tables
( demonstrate SELinux AVC's )


I will clone this comment on this bug into needed SELinux rules requests on the parent packages

The needed additional permissions for SELinux turn out to have had some hidden additional parts needed, and I believe a better rule is:


[root@router ~]# cat my-grep.te

module my-grep 1.0;

require {
        type iptables_t;
        type modules_conf_t;
        class file { getattr ioctl open read };
}

#============= iptables_t ==============

#!!!! This avc is allowed in the current policy
allow iptables_t modules_conf_t:file { getattr ioctl open read };
[root@router ~]#

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0715