RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1020552 - iptraf-ng rpm installs /var/lock/iptraf-ng but should really be using the tmpfiles.d mechanism
Summary: iptraf-ng rpm installs /var/lock/iptraf-ng but should really be using the tmp...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iptraf-ng
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 7.6
Assignee: Phil Cameron
QA Contact: Daniel Rusek
URL:
Whiteboard:
Depends On:
Blocks: 1554861
TreeView+ depends on / blocked
 
Reported: 2013-10-17 22:11 UTC by Andrew J. Schorr
Modified: 2018-10-30 07:49 UTC (History)
7 users (show)

Fixed In Version: iptraf-ng-1.1.4-3.fc19
Doc Type: Bug Fix
Doc Text:
Cause: change in coding requirements Consequence: waring in build Fix: code to current standard Result: no warning
Clone Of:
Environment:
Last Closed: 2018-10-30 07:49:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3030 0 None None None 2018-10-30 07:49:43 UTC

Description Andrew J. Schorr 2013-10-17 22:11:51 UTC 
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 12:37:43 UTC 
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 13:38:46 UTC 
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 11:48:45 UTC 
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 13:36:43 UTC 
That sounds good to me.  Thanks!
Comment 5 Cristian Ciupitu 2014-01-04 06:54:52 UTC 
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 20:17:57 UTC 
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-03 00:29:47 UTC 
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-03 00:29:59 UTC 
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 08:37:51 UTC 
iptraf-ng-1.1.4-3.fc19 works
Comment 11 Cristian Ciupitu 2014-03-03 16:04:24 UTC 
[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 18:43:44 UTC 
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 06:39:30 UTC 
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 06:28:55 UTC 
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-08 03:34:02 UTC 
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 18:11:45 UTC 
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 15:16:05 UTC 
:: [ 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.
Comment 22 errata-xmlrpc 2018-10-30 07:49:17 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3030
Note You need to log in before you can comment on or make changes to this bug.