[Pkg-sysvinit-devel] Bug#406685: initscripts: RAMRUN, RAMLOCK vars/opts are undocumented

[Paolo]

On Sat, Jan 13, 2007 at 08:01:52PM +0100, Petter Reinholdtsen wrote:
> [Paolo]
> > while looking at an issue with tmpfs, to have /var/run *not* tmpfs,
> > I was suggested to check vars in subj but could not find any info on
> > that ( expect inspecting the code itself, of course).
> 
> 'man 5 rcS' should give you some documentation.  Where did you look?

zgrep'd all man/*/* and doc*/* 

given your tip, I checked rcS.5, turns out rcS.5 as well as the other 2 
manpages from initscripts are 0 bytes. Only reason for that I can think 
of is, that /usr ran out of space on a huge upgrade.
Sorry for the noise about that.

> > Also - not sure whether the culprit is this pkg - but on netinstall
> > seems that /var/run defaults to a tmpfs (this is how it gets set in
> > fstab), which break several pkgs that won't restart on boot anymore.
> 
> Neither /var/run nor /var/lock are currently mounted as tmpfs by
> default in Debian.  Any idea how they could become that for you?  I
> know Ubuntu mount these are tmpfs.  Could that be related?

no, this was a freshly netinstall'd notebook, kept in sync with Etch once
a week at min. While I can't recall all opts taken in all steps, I'm sure
I didn't go too fancy - I'm not used to mount even /tmp as tmpfs - but 
the result currently I have is:

# mount -t tmpfs
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /var/lock type tmpfs (rw,size=4m)
tmpfs on /var/run type tmpfs (rw,size=4m)

anyway, whether an install glitch or just me falling asleep on intall/
config, is a secondary point, main one is that RAMRUN - ie /var/run on 
tmpfs - and perhaps others, doesn't look like an acceptable option in Etch 
current, as too many pkgs don't expect volatile dirs under /var/run hence 
fail on (re)boot.
Respective maintainers seems quite reluctant to address that by hacking
their init.d/ scripts. Case in point was clamav-daemon, which didn't start
on boot, expecting /var/run/clamav/ to be already there. Same for virus-DB
updater freshclam.

As for clamav-daemon bug report, bottom line here is, imo,  that such tmpfs 
(RAM* opts) should be disabled till an agreement is made on who is supposed
to maintain such trees on tmpfs umount/remount. And general awareness is
reached - that situation may badly impact system's security.

thanks
--
paolo