Re: Moving /var/run to a tmpfs?
Andreas Metzler <ametzler@downhill.at.eu.org> wrote:
> It has been pointed out to me in http://bugs.debian.org/387699
> that syvinit is going to move /var/run to a tmpfs to solve a long-standing
Yes, having the opportunity to mount /var/run on a tmpfs would be really
nice. Please consider the same for /var/lock, too. Since both IMHO
require a policy-change, it would be one go for both :)
> are checked and mounted. (I do not know how they are going to handle
> the fact that /var/run is needed before /var is mounted, mount --move
> requires kernel 2.6 afaict.)
Relying on 2.6-only features for this is IMHO a no-go. 2.2 as well as
2.4 are maintained kernel-trees and just because the kernel-team seems
to like to live on the bleeding-edge of still heavily-changing kernels
only, there is no need for admins of stable systems to do the same.
> This is nice, but is going to break packages that either ship a
> subdirectory of /var/run in the deb or generate it once in
> postinst and rely on its existence afterwards.
Yes. Anything shipped with a package (and thus being under package
manager's control) being removed afterwards is IMHO a no-go, too.
Therefor, the Debian policy should explicitely forbid packages to ship
files/directories within /var/run and /var/lock and require them to be
created at runtime instead.
> The whole thing is grey territory in FHS, but still I tend to think
> that sysvinit should somehow preserve the (empty) directory structure
> of /var/run through reboots. Either by using some find+tar magic after
> mounting /usr or by keeping /var/run a real directory and keep the
> pre-mount stuff in /var/run/pre-mount. Other thoughts?
Those are all ugly hacks. Preserving structures like this will most
likely open room for race conditions/inconsistencies, i.e. systems that
die after the installation of some packages and before the mirror-magic
kept their state.
A somewhat more stable ugly hack could be to use any of the fs-merge
approaches (unionfs, translucency, ...) to get directories written to
the persistent layer while getting files written to the transient layer.
However, even this remains an ugly hack :)
And the approach to require packages to ship their /var/{run,lock}
directories somewhere else and get them mirrored to their real positions
automagically IMHO is ugly as well and requires quite the same effort as
providing some debhelpers that deal with on-the-fly creation/removal,
while the latter is the most clean approach, IMHO.
regards
Mario
--
Why did the tachyon cross the road?
Because it was on the other side.
Reply to: