Bug 1053176 - mdadm package installs content into volatile /var/run -> /run
Summary: mdadm package installs content into volatile /var/run -> /run
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jes Sorensen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-14 19:21 UTC by Jaromír Cápík
Modified: 2016-02-01 01:59 UTC (History)
5 users (show)

Fixed In Version: mdadm-3.3-6.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-19 17:14:18 UTC
Type: Bug


Attachments (Terms of Use)

Description Jaromír Cápík 2014-01-14 19:21:07 UTC
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

Comment 1 Jaromír Cápík 2014-01-14 19:50:06 UTC
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}/

Comment 2 Jes Sorensen 2014-01-30 10:31:41 UTC
(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

Comment 3 Jaromír Cápík 2014-01-30 16:03:48 UTC
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.

Comment 4 Jes Sorensen 2014-01-30 16:10:10 UTC
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

Comment 5 Paul Howarth 2014-01-31 13:59:43 UTC
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.

Comment 6 Jes Sorensen 2014-01-31 14:25:01 UTC
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

Comment 7 Paul Howarth 2014-01-31 15:31:54 UTC
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.

Comment 8 Jes Sorensen 2014-01-31 15:41:45 UTC
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

Comment 9 Jes Sorensen 2014-02-05 10:03:50 UTC
mdadm-3.3-6 should bring us back to where we should be.

Comment 10 Jaromír Cápík 2014-02-06 17:43:41 UTC
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.

Comment 11 Paul Howarth 2014-02-06 17:53:13 UTC
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?

Comment 12 Jaromír Cápík 2014-02-06 19:07:36 UTC
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.

Comment 13 Paul Howarth 2014-02-06 19:39:34 UTC
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?

Comment 14 Jaromír Cápík 2014-03-19 17:08:22 UTC
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.

Comment 15 Jes Sorensen 2014-03-19 17:14:18 UTC
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


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