Bug 1290327

Summary:	ebtables lock-file is not deleted on reboot
Product:	[Fedora] Fedora	Reporter:	Jens Lody <fedora>
Component:	ebtables	Assignee:	Tom "spot" Callaway <tcallawa>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	23	CC:	tcallawa, twoerner
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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-22 02:20:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jens Lody 2015-12-10 09:07:26 UTC

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 18:32:31 UTC

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 23:06:38 UTC

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 13:24:49 UTC

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 12:57:22 UTC

(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 17:12:07 UTC

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-20 03:52:58 UTC

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-20 03:54:51 UTC

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-22 02:20:19 UTC

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 18:23:07 UTC

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.