Created attachment 767104 [details] firewalld log Hi, 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): Firewalld: 0.3.3 libvirt: 1.0.6 How reproducible: Always 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 Actual results: firewalld-cmd just hangs Expected results: The firewalling state is restored Additional info: 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 Thank you. 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 https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=5818f3ab84245123516dbc1a4eb3015f63aa2869 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 /usr/lib/python2.7/site-packages/firewall/server/decorators.py (the path could differ a little, but I'm sure you'll find it). Find line 56, which says raise DBusException(error) and change (keep the indentation) it to raise DBusException(str(error)) That's it. Now restart firewalld and try to reproduce it.
(In reply to Jiri Popelka from comment #2) > You just need to edit > /usr/lib/python2.7/site-packages/firewall/server/decorators.py Or simply replace it with https://git.fedorahosted.org/cgit/firewalld.git/plain/src/firewall/server/decorators.py
Hi, 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?
nice idea
firewalld-0.3.4-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/firewalld-0.3.4-1.fc19
Package firewalld-0.3.4-1.fc19: * 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: https://admin.fedoraproject.org/updates/FEDORA-2013-14046/firewalld-0.3.4-1.fc19 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.
Hi Jiri, Has the timeout mechanism been actually implemented or has this bug been closed for the initial problem regarding the exception?
Hi, 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 https://lists.fedorahosted.org/mailman/listinfo/firewalld-users because this Bugzilla is meant for problems seen on Fedora/RHEL.