This service will be undergoing maintenance at 03:30 UTC, 2016-05-27. It is expected to last about 2 hours
Bug 722814 - /var/lock/lockdev is lost after reboot - add to tmpfiles.d
/var/lock/lockdev is lost after reboot - add to tmpfiles.d
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: lockdev (Show other bugs)
14
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-18 00:29 EDT by Martin Langhoff
Modified: 2011-07-19 05:05 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-19 05:05:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Martin Langhoff 2011-07-18 00:29:08 EDT
Description of problem:

If the /var/lock/lockdev directory is missing, minicom will error out with "Device /dev/ttyUSB0 lock failed: Operation not permitted."

Version-Release number of selected component (if applicable):

minicom-2.5-6.fc15

How reproducible:

Always

Steps to Reproduce:
1. Plug a serial adapter on /dev/ttyUSB0
2. minicom -s USB0 to configure it
3. minicom USB0
  
Additional info:

Installing the lockdev package _or_ creating the /var/lock/lockdev directory fixed the problem.

A simple fix for this would be to add a lockdev dependency to minicom.
Comment 1 Martin Langhoff 2011-07-18 03:09:25 EDT
Actually - after a bit more diagnosis, the dependency is there, and lockdev is installed in the problem machines.

The issue is with /var/lock/lockdev -- it is lost after reboot. Should be declared in a /etc/tmpfiles.d/ directory. Something like 

$ cat /etc/tmpdiles.d/lockdev.conf
d	/var/lock/lockdev	0775 root lock
Comment 2 Peter Robinson 2011-07-18 05:42:17 EDT
Issue exists in rawhide as well.
Comment 3 Jiri Popelka 2011-07-18 08:40:12 EDT
I had dropped /etc/tmpfiles.d/lockdev.conf from lockdev package because of bug #692714. Moving this BZ to systemd which should ship this file in F15.
Comment 4 Martin Langhoff 2011-07-18 12:05:22 EDT
Note that this issue affects F14 as well (and this impacts OLPC OS releases).

Even if systemd gets this fixed on F15/rawhide, F14 needs /etc/tmpfiles.d/lockdev.conf
Comment 5 Lennart Poettering 2011-07-18 16:25:23 EDT
Hmm, /usr/lib/tmpfiles.d/legacy.conf creates that directory, so it should be there. Are you suggesting this file is not existant for you?
Comment 6 Martin Langhoff 2011-07-19 02:21:22 EDT
Actually, you are right, and my repro test on F15 was wrong, so systemd is in the clear. Reassigning to lockdev.

The problem repros on F14 -- the F14 package in fedpkg needs to get some bits from commit 76efe301a85adf8470f72569c6a90d8fd4c2a8e5 .

In other words - the change was applied for F15 and then removed in favour of the systemd fix. That initial change needs to be applied to F14.

Thanks!
Comment 7 Jiri Popelka 2011-07-19 04:56:26 EDT
The https://fedoraproject.org/wiki/Features/var-run-tmpfs
is F15 feature so the /var/lock/lockdev should survive reboot on F14.
Adding /etc/tmpfiles.d/lockdev.conf to F14 doesn't change anything.
Or am I wrong, Lennart ?
Comment 8 Martin Langhoff 2011-07-19 05:04:50 EDT
Gaah. Peter Robinson just pointed out that I see this on F14 because at OLPC we have backported var-run-tmpfs to our custom F14.

So this bug is invalid (in Fedora), and I apologize for having bothered everyone with it. On the upside, you have helped me diagnose a bug in OLPC's build, which is used by >1.5M children around the world .

Thanks for your patience.

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