Bug 1020552 - iptraf-ng rpm installs /var/lock/iptraf-ng but should really be using the tmpfiles.d mechanism
iptraf-ng rpm installs /var/lock/iptraf-ng but should really be using the tmp...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iptraf-ng (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: 7.6
Assigned To: Phil Cameron
: Reopened
Depends On:
Blocks: 1554861
  Show dependency treegraph
Reported: 2013-10-17 18:11 EDT by Andrew J. Schorr
Modified: 2018-05-02 11:16 EDT (History)
7 users (show)

See Also:
Fixed In Version: iptraf-ng-1.1.4-3.fc19
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-07 01:28:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew J. Schorr 2013-10-17 18:11:51 EDT
Description of problem:
If you install iptraf-ng and then reboot, rpm reports that /var/lock/iptraf-ng
is missing:

bash-4.2$ rpm --verify iptraf-ng
missing     /var/lock/iptraf-ng

Instead of trying to install the /var/lock/iptraf-ng directory, it should
use the tmpfiles.d mechanism to create this directory, since /run/lock
is now created that way:

bash-4.2$ grep /run/lock /usr/lib/tmpfiles.d/legacy.conf | head -1
d /run/lock 0755 root root -

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

How reproducible:
Install iptraf-ng, reboot, then run rpm --verify

Steps to Reproduce:
1. Install iptraf-ng rpm
2. Reboot
3. Run "rpm --verify iptraf-ng" and note the error.

Actual results:
missing     /var/lock/iptraf-ng

Expected results:
No complaints.

Additional info:
Comment 1 Nikola Pajkovsky 2013-10-18 08:37:43 EDT
Hello Andrew,

yeah, true. The whole story happened when /var/lock became symlink to /run/lock and /run was mounted as tmpfs. Hence, I had two options to address this issue.
1) your solution, 2) write sanity check for lock directory in iptraf-ng. I did 2) and that's why you don't see any issues (when run iptraf-ng, dir is created if not exists).

Nevertheless, I should drop iptraf-ng.conf to /usr/lib/tmpfiles.d/.
Comment 2 Andrew J. Schorr 2013-10-18 09:38:46 EDT
Hi Nikola,

I'm not sure of the correct fix, because it seems as if using /var/lock
is deprecated.  Or that's how I interpret this comment in /usr/lib/tmpfiles.d/legacy.conf:

bash-4.2$ head -13 /usr/lib/tmpfiles.d/legacy.conf
#  This file is part of systemd.
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

# These files are considered legacy and are unnecessary on legacy-free
# systems.

d /run/lock 0755 root root -

This gives the impression that one should avoid using /run/lock (or /var/lock).
I'm not sure what the correct solution is.  Maybe the iptraf-ng locking
directory should be direcly under /run rather than /run/lock.  If under /run/lock,
I wonder if there's a race condition regarding which tmpfiles.d file gets 
processed first.

Comment 3 Nikola Pajkovsky 2013-11-18 06:48:45 EST
sorry for long delay, I should buy you a beer.

It seems it's another way around, see

$ ll /var/ | grep lock
lrwxrwxrwx.  1 root root   11 Oct 18 13:58 lock -> ../run/lock

and according packaging guide lines (http://fedoraproject.org/wiki/Packaging:Tmpfiles.d) I should create lock file right into /run.
Comment 4 Andrew J. Schorr 2013-11-18 08:36:43 EST
That sounds good to me.  Thanks!
Comment 5 Cristian Ciupitu 2014-01-04 01:54:52 EST
When this is implemented, please make sure that the file mode is the
same in %files section of the RPM SPEC and the tmfiles config file.
Right now I'm getting this with iptraf-ng-1.1.4-3.fc20.x86_64:

# rpm -V -f /var/lock/iptraf-ng
.M.......    /var/lock/iptraf-ng
Comment 7 Fedora Admin XMLRPC Client 2014-02-05 15:17:57 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Update System 2014-03-02 19:29:47 EST
iptraf-ng-1.1.4-5.fc20 has been submitted as an update for Fedora 20.
Comment 9 Fedora Update System 2014-03-02 19:29:59 EST
iptraf-ng-1.1.4-3.fc19 has been submitted as an update for Fedora 19.
Comment 10 lnie 2014-03-03 03:37:51 EST
iptraf-ng-1.1.4-3.fc19 works
Comment 11 Cristian Ciupitu 2014-03-03 11:04:24 EST
[root@hermes ~]# rpm -q iptraf-ng 
[root@hermes ~]# rpm -V iptraf-ng 
missing     /var/lock/iptraf-ng
Comment 12 Alejandro_Perez 2014-03-03 13:43:44 EST
On f20 you need to test https://admin.fedoraproject.org/updates/iptraf-ng-1.1.4-5.fc20
Comment 13 Fedora Update System 2014-03-04 01:39:30 EST
Package iptraf-ng-1.1.4-5.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing iptraf-ng-1.1.4-5.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 14 Fedora Update System 2014-03-07 01:28:55 EST
iptraf-ng-1.1.4-5.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2014-03-07 22:34:02 EST
iptraf-ng-1.1.4-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Andrew J. Schorr 2016-11-02 14:11:45 EDT
If I'm not mistaken, this same issue applies to the RHEL 7.2 version of the package.
Comment 20 Daniel Rusek 2018-05-02 11:16:05 EDT
:: [ 11:14:43 ] :: [   PASS   ] :: Command 'rpm --verify iptraf-ng' (Expected 0, got 0)
:: [ 11:14:43 ] :: [   PASS   ] :: File '/var/tmp/rlRun_LOG.BO0K9C8m' should not contain 'missing     /var/lock/iptraf-ng'

I can confirm that this is fixed since RHEL 7.3.

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