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...
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iptraf-ng (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Alejandro_Perez
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-17 18:11 EDT by Andrew J. Schorr
Modified: 2017-10-03 21:28 EDT (History)
3 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:
Environment:
Last Closed: 2014-03-07 01:28:55 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 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):
iptraf-ng-1.1.4-2.fc19.x86_64


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.

Regards,
Andy
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.
https://admin.fedoraproject.org/updates/iptraf-ng-1.1.4-5.fc20
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.
https://admin.fedoraproject.org/updates/iptraf-ng-1.1.4-3.fc19
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 
iptraf-ng-1.1.4-3.fc20.x86_64
[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:
https://admin.fedoraproject.org/updates/FEDORA-2014-3373/iptraf-ng-1.1.4-5.fc20
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.

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