Bug 979790 - [RFE] firewalld-cmd should timeout instead of hanging forever when no reply comes over D-Bus
Summary: [RFE] firewalld-cmd should timeout instead of hanging forever when no reply c...
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-30 15:28 UTC by Laurent Bigonville
Modified: 2013-08-15 15:56 UTC (History)
2 users (show)

Fixed In Version: firewalld-0.3.4-1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-08-04 00:09:17 UTC
Type: Bug

Attachments (Terms of Use)
firewalld log (48.04 KB, text/x-log)
2013-06-30 15:28 UTC, Laurent Bigonville
no flags Details

Description Laurent Bigonville 2013-06-30 15:28:49 UTC
Created attachment 767104 [details]
firewalld log


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:

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)

Comment 1 Laurent Bigonville 2013-06-30 15:43:46 UTC
OK, I can reproduce this if I try to delete any non-existing rules

Comment 2 Jiri Popelka 2013-07-01 15:18:51 UTC
(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

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 
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.

Comment 3 Jiri Popelka 2013-07-01 15:26:51 UTC
(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

Comment 4 Laurent Bigonville 2013-07-01 15:36:41 UTC

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

Comment 5 Laurent Bigonville 2013-07-01 15:38:59 UTC
Shouldn't a timeout be added in firewall-cmd in case of something is going wrong on the bus?

Comment 6 Jiri Popelka 2013-07-01 16:15:18 UTC
(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 ?

Comment 7 Laurent Bigonville 2013-07-01 16:21:12 UTC
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?

Comment 8 Jiri Popelka 2013-07-01 16:46:03 UTC
nice idea

Comment 9 Fedora Update System 2013-07-30 19:13:44 UTC
firewalld-0.3.4-1.fc19 has been submitted as an update for Fedora 19.

Comment 10 Fedora Update System 2013-08-02 03:48:40 UTC
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:
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2013-08-04 00:09:17 UTC
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.

Comment 12 Laurent Bigonville 2013-08-05 23:59:13 UTC
Hi Jiri,

Has the timeout mechanism been actually implemented or has this bug been closed for the initial problem regarding the exception?

Comment 13 Jiri Popelka 2013-08-15 15:56:52 UTC

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.

Note You need to log in before you can comment on or make changes to this bug.