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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
