1、故障現象
在一個生產服務器上，系統為CentOS7.3，防火牆使用的是系統默認的firewalld。偶然發現，在執行以下防火牆管理命令時，報錯如下：
# firewall-cmd --list-all
Error: Action org.fedoraproject.FirewallD1.config.info is not registered
雖然查看防火牆配置規則列表的命令報錯了，但其它的規則配置命令仍然能正常使用，只是配置完后，沒辦法通過命令查看配置結果。不管是查看service，還是port，還是all，都會報上面的錯誤。
2、問題排查
（1）先查看firewalld服務的運行狀態和事件日志信息，如下所示：
# systemctl status firewalld -l
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since 三 2018-04-25 21:23:25 CST; 3h 15min ago
Docs: man:firewalld(1)
Main PID: 168206 (firewalld)
CGroup: /system.slice/firewalld.service
└─168206 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --destination 192.168.122.0/24 --out-interface virbr0 --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --source 192.168.122.0/24 --in-interface virbr0 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --in-interface virbr0 --out-interface virbr0 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --out-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name.
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete FORWARD --in-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name.
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 53 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 53 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete OUTPUT --out-interface virbr0 --protocol udp --destination-port 68 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 67 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
4月 25 21:23:26 localhost firewalld[168206]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
分析：
從上述內容中首先可以看到的是，firewalld服務狀態運行是正常的。
其次是服務的事件日志中打印了一些warning信息，這些信息比較有誤導性。需要明確的一點是，warning級別的事件，還不足以對服務和管理命令的正常使用造成影響，所以這里可以忽略這些warning信息。
（2）考慮到這些warning信息是關於網橋virbr0的，而這台服務器上恰好配置了kvm虛擬化，也使用了一個br0的網橋。所以有必要查看一下libvirtd服務的運行狀態。
# systemctl status libvirtd -l
● libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
Active: active (running) since 二 2018-01-23 00:27:07 CST; 3 months 1 days ago
Docs: man:libvirtd(8)
http://libvirt.org
Main PID: 1417 (libvirtd)
CGroup: /system.slice/libvirtd.service
├─1417 /usr/sbin/libvirtd
├─2869 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
└─2870 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
1月 23 00:27:08 localhost dnsmasq[2869]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
1月 23 00:27:08 localhost dnsmasq-dhcp[2869]: read /var/lib/libvirt/dnsmasq/default.hostsfile
1月 24 10:51:23 localhost libvirtd[1417]: 2018-01-24 02:51:23.271+0000: 1417: info : libvirt version: 3.2.0, package: 14.el7_4.5 (CentOS BuildSystem <http://bugs.centos.org>, 2017-12-07-15:37:23, c1bm.rdu2.centos.org)
1月 24 10:51:23 localhost libvirtd[1417]: 2018-01-24 02:51:23.271+0000: 1417: info : hostname: localhost
1月 24 10:51:23 localhost libvirtd[1417]: 2018-01-24 02:51:23.271+0000: 1417: error : virNetSocketReadWire:1808 : 讀取數據時進入文件終點: 輸入/輸出錯誤
4月 25 19:22:34 localhost libvirtd[1417]: 2018-04-25 11:22:34.364+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
4月 25 20:37:48 localhost libvirtd[1417]: 2018-04-25 12:37:48.301+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
4月 25 21:04:14 localhost libvirtd[1417]: 2018-04-25 13:04:14.186+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
4月 25 21:19:29 localhost libvirtd[1417]: 2018-04-25 13:19:29.834+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
4月 25 21:23:25 localhost libvirtd[1417]: 2018-04-25 13:23:25.666+0000: 1417: error : virFirewallApplyRuleFirewallD:790 : The name org.fedoraproject.FirewallD1 was not provided by any .service files
分析：
從上述libvirtd服務的信息可以看到服務運行正常；
有一些error事件，仔細查看事件時間和內容，發現都是和firewalld服務相關。其中的org.fedoraproject.FirewallD1剛好是firewalld服務在系統dbus服務中注冊的服務名稱。
經過反復分析，證實了這些libvirtd的error事件實際上是因為我在重啟firewalld服務時所引發的。因為libvirtd服務使用了firewalld服務，自然在firewalld服務不可用時，報出的一些error日志。所以從libvirtd服務中沒有找到任何可以對排查firewall-cmd --list-all命令在執行時報錯有幫助的信息。
（3）重新回到最初的報錯信息，在google上以多種關鍵字組合進行搜索
Error: Action org.fedoraproject.FirewallD1.config.info is not registered
對幾十個搜索結果進行了對比分析后，發現完全相同的現象沒有，故障現象接近的大概有兩種。
一種是說，重新操作系統后，故障現象會消失。考慮到我們是生產服務器，這個方法顯然行不通。
另一種說法是，這個問題是firewalld軟件的一個bug。只是紅帽網站上這個文章的時間已經在2015年，近4年前的更舊操作系統上更舊的firewalld版本中的問題。
與此同時，還排查了/var/log/message, /var/log/firewalld.log等日志文件。雖有一些值得注意的信息，但在深入分析、對照正常系統后，均排除掉了。
也對/usr/lib/systemd/system/目錄下的systemd管理的firewalld服務相關的.service文件進行了反復的分析、關聯分析。同樣是沒有任何線索。
3、問題的解決
考慮到在firewalld舊版本上曾發生過的一個bug，決定也升級一下firewalld的軟件版本試試。
當前使用的是centos7.3系統，firewalld的版本信息如下所示：
# rpm -qa firewalld
firewalld-0.4.3.2-8.el7.noarch
執行針對firewalld軟件包的升級命令：
[root@localhost log]# yum update firewalld
依賴關系解決
==================================================================================================================================================================================
Package 架構 版本 源 大小
==================================================================================================================================================================================
正在更新:
firewalld noarch 0.4.4.4-6.el7 base 416 k
selinux-policy noarch 3.13.1-166.el7_4.9 updates 437 k
為依賴而更新:
firewalld-filesystem noarch 0.4.4.4-6.el7 base 47 k
python-firewall noarch 0.4.4.4-6.el7 base 325 k
selinux-policy-targeted noarch 3.13.1-166.el7_4.9 updates 6.5 M
升級成功后，查看firewalld的版本變成了：
[root@localhost log]# rpm -qa firewalld
firewalld-0.4.4.4-6.el7.noarch
此時再次執行firewall-cmd --list-all的命令查看防火牆的配置規則列表：
# firewall-cmd --list-all
public
target: default
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="123.123.123.123/32" port port="22" protocol="tcp" accept
rule family="ipv4" source address="172.17.10.1/32" port port="22" protocol="tcp" accept
原來的故障現象消失了，在執行systemctl restart firewalld后再次使用firewall-cmd --list-all的命令查看防火牆的配置規則列表，一切正常。
該問題的根源原因，大概率上仍然集中在firewalld軟件的bug上了，只是曾修復過的bug，怎么又到未來某個新版本中故地重游了呢，費解。