Red Hat Bugzilla – Bug 1020552
iptraf-ng rpm installs /var/lock/iptraf-ng but should really be using the tmpfiles.d mechanism
Last modified: 2017-10-03 21:28:51 EDT
Description of problem:
If you install iptraf-ng and then reboot, rpm reports that /var/lock/iptraf-ng
bash-4.2$ rpm --verify 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):
Install iptraf-ng, reboot, then run rpm --verify
Steps to Reproduce:
1. Install iptraf-ng rpm
3. Run "rpm --verify iptraf-ng" and note the error.
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/.
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
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
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.
That sounds good to me. Thanks!
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
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
iptraf-ng-1.1.4-5.fc20 has been submitted as an update for Fedora 20.
iptraf-ng-1.1.4-3.fc19 has been submitted as an update for Fedora 19.
[root@hermes ~]# rpm -q iptraf-ng
[root@hermes ~]# rpm -V iptraf-ng
On f20 you need to test https://admin.fedoraproject.org/updates/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).
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.
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.
If I'm not mistaken, this same issue applies to the RHEL 7.2 version of the package.