Bug 1290327 - ebtables lock-file is not deleted on reboot
ebtables lock-file is not deleted on reboot
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ebtables (Show other bugs)
23
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-10 04:07 EST by Jens Lody
Modified: 2016-01-28 13:23 EST (History)
2 users (show)

See Also:
Fixed In Version: ebtables-2.0.10-18.fc23 ebtables-2.0.10-18.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-21 21:20:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jens Lody 2015-12-10 04:07:26 EST
Description of problem:
ebtables uses a lock file, if it is started with --concurrent parameter.
If the system crashes the lock file might exist on startup.
This makes firewalld.service hang and run in a timeout and virt-manager can noct connect to qemu:///system. It hangs forever in connecting without any meaningful debug-message.

Version-Release number of selected component (if applicable):
2.0.10-17.fc23 (and most likely others)

How reproducible:
Always

Steps to Reproduce:
1.Create a lockfile manually with "sudo touch /var/lib/ebtables/lock"
2.reboot
3.see firewalld.service timeout on startup, try to connect to qemu:///system

Actual results:
timeout or hang

Expected results:
lock-file should be removed on startup

Additional info:
I set the severity to high, because a not working firewall is a possible security risk.
Comment 1 Tom "spot" Callaway 2015-12-14 13:32:31 EST
I'm not sure how to do this. The only time that ebtables cares about the lock file is when it is run with --concurrent, but if we tell ebtables to delete the lock file on startup when we exec it with --concurrent, we defeat the entire point of the lock file.

You're launching ebtables from firewalld.service (I know this because firewalld.service has Conflicts: ebtables.service). Since firewalld hangs, that means firewalld is invoking ebtables --concurrent.

Thomas, do you have any ideas how to resolve this?
Comment 2 Jens Lody 2015-12-14 18:06:38 EST
Maybe my description was somewaht unclear.
I don't mean the lockfile should be deleted on startup of ebtables, but when the system boots.
After booting the system, I was not able to connect to the qemu-service.
When looking at the boot-process I saw that the start of firewalld.service timed out.
A lock-file for ebtables exists, after deleting it, I was able to (re-)start the firewalld.service.
After also restarting the libvirtd.service (even if it was running) I was able to connect to qemu://system.

I changed the title of the bug to be more clear.
Comment 3 Thomas Woerner 2015-12-18 08:24:49 EST
A lock file location of /var/lib is not optimal as it is not cleaned up automatically on reboot.

iptables is using a better lock file location: /run/xtables.lock
Additionally it is using flock on the file for locking.

For now I have added a patch to firewalld upstream (https://github.com/t-woerner/firewalld/commit/f431547ffe3369daeec46c781fda68eff7747a81) to remove the ebtables lock file /var/lib/ebtables/lock if the lock exists but ebtables is not running. This is only a sub optional work a round and not a good solution, as it will only fix the use of ebtables in firewalld, but not in other consumers like libvirt for example. Also this patch is not applied to firewalld packages in Fedora yet.
Comment 4 Jens Lody 2015-12-19 07:57:22 EST
(In reply to Thomas Woerner from comment #3)
> A lock file location of /var/lib is not optimal as it is not cleaned up
> automatically on reboot.
> 

That means the best fix would be to use another lock-file location for ebtables, so dangling lock-files are removed automatically on boot.
Comment 5 Fedora Update System 2016-01-18 12:12:07 EST
ebtables-2.0.10-18.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a15431a25
Comment 6 Fedora Update System 2016-01-19 22:52:58 EST
ebtables-2.0.10-18.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5bdb76af0b
Comment 7 Fedora Update System 2016-01-19 22:54:51 EST
ebtables-2.0.10-18.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0a15431a25
Comment 8 Fedora Update System 2016-01-21 21:20:19 EST
ebtables-2.0.10-18.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2016-01-28 13:23:07 EST
ebtables-2.0.10-18.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

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