[Bug 1645324] Re: ebtables: Lock file should be moved from /var/lib/ebtables to /run

Louis Bouchard louis.bouchard at canonical.com
Fri Jan 27 11:00:40 UTC 2017


** Changed in: ebtables (Ubuntu Trusty)
       Status: New => Triaged

** Changed in: ebtables (Ubuntu Trusty)
       Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1645324

Title:
  ebtables: Lock file should be moved from /var/lib/ebtables to /run

Status in ebtables package in Ubuntu:
  Fix Released
Status in ebtables source package in Trusty:
  In Progress
Status in ebtables package in Debian:
  Fix Released

Bug description:
  [Impact]
  ebtables uses a lock file, if it is started with --concurrent parameter.
  Everytime ebtables is run in trusty, a lock file is created in /var/lib/ebtables/.

  If the system crashes the lock file might exist on startup. This makes
  libvirtd and other services to hang after startup that depends on
  ebtables.

  Lockfile should probably be moved to /run instead, especially that the
  initscript is not taking care of cleaning that lockfile at startup.

  [Test Case]
  1.Create a lockfile manually with "sudo touch /var/lib/ebtables/lock"
  2.reboot
  3.libvird hanging, try to connect to qemu:///system

  testcase2:
  1. $ while true; do /usr/sbin/ebtables --concurrent -L; done
  2. hard reboot VM
  3. likely that the lock file is present under /var/lib/ebtables
  4. libvird hanging, try to connect to qemu:///system

  [Regression Potential]
  There should be minimal regression potential in this patch

  [Original Text]
  libvirtd is hanging after startup due to ebtables lock file -from an earlier run- remains intact when the system reboots. 
  Same issue is happening than it is reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1290327 when the system boots. 

  After booting the system, It's not possible connect to the qemu-service. 
  - libvirt daemon tried to obtain a lock: 
  [pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45 
  [pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2, 4294967295) = 1 ([{fd=24, revents=POLLIN}]) 
  [pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45 
  [pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2, 4294967295) = 1 ([{fd=24, revents=POLLIN}]) 
  [pid 20966] read(24, "Trying to obtain lock /var/lib/e"..., 1024) = 45 
  [pid 20966] poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2, 4294967295^CProcess 20916 detached 

  - there was a file named 'lock' in /var/lib/ebtables directory with timestamp 14:54 
  - ebtables was configured: 
  * Ebtables support available, number of installed rules [ OK ] 
  (other nodes appeared to be in the same state from ebtables point of view, but without the lock file) 
  - I removed the lock file and libvirt started to work instantly - the lock obtain messages have disappeared from the trace and virsh commands are working 
  - at 14:54 the host was booting up. According to the logs, there were other reboots after that one, but the lock file remained intact (at least the timestamp was not updated). 

  Could you please suggest a solution to be sure that ebtables lock file
  is removed during boot?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1645324/+subscriptions



More information about the Ubuntu-sponsors mailing list