Description of problem: Hello. As /run is mounted as tmpfs, the content is erased with each reboot and therefore it doesn't make sense to install anything into that directory. The following packages need to be fixed ... $ repoquery --whatprovides /var/run/* avahi-0:0.6.31-23.fc21.x86_64 avahi-0:0.6.31-23.fc21.i686 pam-0:1.1.8-4.fc21.x86_64 pam-0:1.1.8-4.fc21.i686 cups-1:1.7.1-1.fc21.x86_64 dbus-1:1.6.18-2.fc21.x86_64 pam-0:1.1.8-4.fc21.x86_64 pam-0:1.1.8-4.fc21.i686 mdadm-0:3.3-4.fc21.x86_64 initscripts-0:9.50-2.fc21.x86_64 ppp-0:2.4.5-33.fc20.x86_64 screen-0:4.1.0-0.17.20120314git3c2946.fc20.x86_64 pam-0:1.1.8-4.fc21.x86_64 pam-0:1.1.8-4.fc21.i686 libselinux-0:2.2.2-1.fc21.x86_64 libselinux-0:2.2.2-1.fc21.i686 initscripts-0:9.50-2.fc21.x86_64
According to the following changelog line the /var/run directory should be ghosted. - Ghost the directory in /var/run, create /var/run/mdadm in mdmonitor init .... but I don't see any ghost keyword and the directory is created as a regular one %dir %{_localstatedir}/run/%{name}/
(In reply to Jaromír Cápík from comment #1) > According to the following changelog line the /var/run directory should be > ghosted. > - Ghost the directory in /var/run, create /var/run/mdadm in mdmonitor init > > .... but I don't see any ghost keyword and the directory is created as a > regular one > > %dir %{_localstatedir}/run/%{name}/ That comment is dated March 2011, it's rather obsolete by now. If you look further, you will notice /usr/lib/tmpfiles.d/mdadm.conf: [jes@ultrasam mdadm-fedora]$ cat /usr/lib/tmpfiles.d/mdadm.conf d /var/run/mdadm 0710 root root - Do we need anything else? The /var/run/mdadm directory is created in the .spec file, but nothing is copied in there. I can remove the creation of the directory from the .spec, but it is really just noise. Jes rpm -qlp ~/rpmbuild/RPMS/x86_64/mdadm-3.3-4.fc20.x86_64.rpm /etc/cron.d/raid-check /etc/libreport/events.d/mdadm_event.conf /etc/sysconfig/raid-check /usr/lib/systemd/system/mdmon@.service /usr/lib/systemd/system/mdmonitor.service /usr/lib/tmpfiles.d/mdadm.conf /usr/lib/udev/rules.d/63-md-raid-arrays.rules /usr/lib/udev/rules.d/64-md-raid-assembly.rules /usr/lib/udev/rules.d/65-md-incremental.rules /usr/sbin/mdadm /usr/sbin/mdmon /usr/sbin/raid-check /usr/share/doc/mdadm /usr/share/doc/mdadm/COPYING /usr/share/doc/mdadm/ChangeLog /usr/share/doc/mdadm/TODO /usr/share/doc/mdadm/mdadm.conf-example /usr/share/doc/mdadm/syslog-events /usr/share/man/man4/md.4.gz /usr/share/man/man5/mdadm.conf.5.gz /usr/share/man/man8/mdadm.8.gz /usr/share/man/man8/mdmon.8.gz /var/run/mdadm
Hello Jes. The question is whether the directory is needed by mdadm in between the installation and the consequent reboot. If that's the case, then the directory should be created with proper rights in the %post section. I believe it shouldn't be contained in the cpio archive. It's up to you to decide whether this needs to be fixed or not. If you believe it's just a noise, then close the report as WONTFIX or NOTABUG. Thanks, Jaromir.
Jaromir, Oh that is a good point, I hadn't thought of the install problem. Yes the directory is definitely going to be needed during installation, if a user opts to install onto raid partitions. Guess I'll have to respin the fixes I just put into my local tree :) Cheers, Jes
The tmpfiles.d packaging guidelines suggest that the original method of including the directory in the %files list and packaging the tmpfiles config file is the right way to do it: https://fedoraproject.org/wiki/Packaging:Tmpfiles.d This also ensures that an rpm database query about who owns the directory in question returns the correct package.
OK, so what is the right solution here? I pushed changes in based on Jaromir's comments earlier, but I agree that having rpm know about the directory is a good thing. If this is the right solution, then mdadm-3.3-5 should be reverted. Jes
I think the solution in the example in the guidelines is the right way, and it's what I do in the packages I maintain. In other words, I think what you had was right in the first place.
Paul, The more I think of it, the more I agree with you. I am going to revert the 3.3-5 changes unless someone comes up with a real good explanation why I shouldn't within the next couple of hours. Anyone asking for it to be changed again after that will receive a sack of coal for xmas. Jes
mdadm-3.3-6 should bring us back to where we should be.
Guys ... I belive the best solution is to mark the directory with the %ghost keyword so that the package is the directory owner. But I see as incorrect to keep the directory in the CPIO archive. If the directory is needed in between the installation and the consequent reboot and the tools are unable to create the directory with the right permissions, then the directory should be created during the %post.
The directory can already be created with the correct permissions, ownership and SELinux context by including it in the %files list as normal. What's to be gained by adding "%ghost" and a "%post" script?
Hi Paul. I'm talking about corner usecases, where you need to unpack the cpio content in a directory where no tmpfs mountpoints exist at that time, but if you believe it isn't worthy to consider cases like that, please ignore my comments. I accept your attitude. No problem.
I'm not trying to be antagonistic here, I just want to understand why you think having to have a %post script is an improvement. Considering your corner case, where you're unpacking the rpm where there's no tmpfs mountpoint at the time, why is that a problem?
Hi Paul. It's about producing and keeping a mess in the filesystem. It is not a big issue. The proposed is just a bit cleaner solution. Feel free to close as WONTFIX.
Jaromir, Well I would have to fix it, and I think the conclusion is that this doesn't make things better, so I am closing it WONTFIX. Cheers, Jes