[Pkg-sysvinit-devel] Bug#607136: initscripts: mountkernfs.sh: illegal handling of _non_-virtual filesystems (RAMRUN mode), leading to multiple daemon startup failure

[Andreas Mohr]

Package: initscripts
Version: 2.86.ds1-61

I kept wondering why openvpn failed on each bootup attempt every couple of weeks.

Now I know that this is because mountkernfs.sh illegally attempts to
additionally handle RAMRUN mode:

        # Mount /var/run and /var/lock as tmpfs if enabled
        if [ yes = "$RAMRUN" ] ; then
                RUN_OPT=
                [ "${RUN_SIZE:=$TMPFS_SIZE}" ] && RUN_OPT=",size=$RUN_SIZE"
                domount tmpfs "" /var/run varrun -omode=0755,nosuid$RUN_OPT
                touch /var/run/.ramfs
        fi
        if [ yes = "$RAMLOCK" ] ; then
                LOCK_OPT=
                [ "${LOCK_SIZE:=$TMPFS_SIZE}" ] && LOCK_OPT=",size=$LOCK_SIZE"
                domount tmpfs "" /var/lock varlock -omode=1777,nodev,noexec,nosuid$LOCK_OPT
                touch /var/lock/.ramfs
        fi

IMHO mountkernfs.sh is so early in bootup stage that it shouldn't
have any business dealing with _any_ directory components which are non-virtual.
Probably someone misplaced this RAMRUN stuff since he thought that RAMRUN is a virtual
fs (tmpfs), however the intent of mountkernfs.sh IMHO is not so much about the _type_
of file system that is being processed, but about the _destination_ of the mount
(namely, being fully virtual on a _root_-partition-based mount point).

In my case of a flash-based server I have a mount that I have /var as a _symlink_ pointing to
(yes, I know, bad dog, no cookies).
However I'd say simply deciding to mount /var as an extra partition
(a fully legal and often-implemented way) is entirely equivalent to my symlink HACK,
since both methods would make /var available at the same time during bootup.

And that's simply not at that point in time when mountkernfs.sh RAMRUN parts
already attempt to do their tweaking.

mountkernfs.sh very early --> no /var tree (mount or directory) available --> RAMRUN tmpfs mount fails
--> usual persistent /var/run directory will appear somewhat later
--> /var/run cleanup will get skipped by mountall-bootclean.sh due to simple RAMRUN=true check
--> stale PID files left in /var/run --> FUBAR


Conclusion: RAMRUN parts should not get handled at dangerously early mountkernfs.sh stage due to
/var tree involvement.
Or RAMRUN would have to state a "fixed /var tree" requirement - but in such a case
the mountall-bootclean.sh /var/run cleanup check should not be done simply based on
having RAMRUN set to true, but instead on whether it's _actually_ tmpfs-based or not.

Thanks,

Andreas Mohr