Red Hat Bugzilla – Bug 979790
[RFE] firewalld-cmd should timeout instead of hanging forever when no reply comes over D-Bus
Last modified: 2013-08-15 11:56:52 EDT
Created attachment 767104 [details]
Description of problem:
On debian unstable, I've recompiled libvirt with firewalld support. If the firewalld daemon is restarted while the libvirt network (virbr0) interface is up, all the calls to firewalld-cmd just hang.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Enable libvirt network interface (virbr0)
2. Restart firewalld daemon without bringing the interface down
3. The needed firewalling rules are not loaded and there are firewalld-cmd commands blocked
firewalld-cmd just hangs
The firewalling state is restored
When libvirt is seeing firewalld reappears on the bus, it seems to try to drop all the old rules that are sill present. For some reason, firewalld fails to commit (see backtrace) and the firewalld-cmd just hangs. Killing the blocked firewalld-cmd command allows the next one to be executed with exactly the same backtrace and it just hangs again (and so on)
OK, I can reproduce this if I try to delete any non-existing rules
(In reply to Laurent Bigonville from comment #0)
> firewalld log
The traceback is quite cryptic but I think I found one part in firewalld which could be related with this. I've pushed the possible fix upstream
It'd be great if you could help me test it somehow, because I can't see this problem on Fedora.
You just need to edit
(the path could differ a little, but I'm sure you'll find it).
Find line 56, which says
and change (keep the indentation) it to
That's it. Now restart firewalld and try to reproduce it.
(In reply to Jiri Popelka from comment #2)
> You just need to edit
Or simply replace it with
Seems to work.
The server part is now giving:
2013-07-01 17:33:55 DEBUG1: direct.passthrough('ipv4', '--table=nat','--delete=POSTROUTING')
2013-07-01 17:33:55 DEBUG2: firewall.core.ipXtables.ip4tables: /sbin/iptables --table=nat --delete=POSTROUTING
2013-07-01 17:33:55 DEBUG2: '/sbin/iptables --table=nat --delete=POSTROUTING' failed: iptables: Bad rule (does a matching rule exist in that chain?).
2013-07-01 17:33:55 DEBUG1: COMMAND_FAILED: '/sbin/iptables --table=nat --delete=POSTROUTING' failed: iptables: Bad rule (does a matching rule exist in that chain?).
And firewall-cmd is returning immediately with:
Error: COMMAND_FAILED: '/sbin/iptables --table=nat --delete=POSTROUTING' failed: iptables: Bad rule (does a matching rule exist in that chain?).
Python-dbus here is at version 1.2.0 and the python version is 2.7.5
Shouldn't a timeout be added in firewall-cmd in case of something is going wrong on the bus?
(In reply to Laurent Bigonville from comment #5)
> Shouldn't a timeout be added in firewall-cmd in case of something is going
> wrong on the bus?
Not sure I understand. Could you elaborate more on that ?
The firewall-cmd is hanging forever because it doesn't receive any reply from the daemon. Shouldn't the command timeout after some times just in case?
firewalld-0.3.4-1.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing firewalld-0.3.4-1.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
firewalld-0.3.4-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Has the timeout mechanism been actually implemented or has this bug been closed for the initial problem regarding the exception?
it's been closed because I hope the initial problem could be fixed now.
Regarding the timeout - there's been a timeout mechanism in D-Bus, we just have no idea why it doesn't work on Debian (or what actually is the problem there).
If you have more problems (I for example can't remember why I haven't replied your comment #4), it'd be better to open new bug - or maybe (if you see it on Debian) send it to upstream mailing list
because this Bugzilla is meant for problems seen on Fedora/RHEL.