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

[Paolo]

On Sun, Jan 14, 2007 at 11:33:24AM +0100, Petter Reinholdtsen wrote:
> Very strange.  What is the content of your /etc/default/rcS and
> /usr/share/initscripts/default.rcS ?  All should list 'no' as the
> setting for these options.

/etc/default/rcS
TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=no
VERBOSE=yes
FSCKFIX=yes

/usr/share/initscripts/default.rcS
TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=yes
VERBOSE=no
FSCKFIX=no
RAMRUN=no
RAMLOCK=no

> > acceptable option in Etch current, as too many pkgs don't expect
> > volatile dirs under /var/run hence fail on (re)boot.
> 
> Well, mounting /var/run/ and /var/lock/ as tmpfs has been expected to
> work in Debian for a long time, and the packages failing to handle it

it'd add lot of hassles on Sarge. Too many manual adjustments.

> Well, these packages need to fix their init.d scripts.

hm, but that's your opinion, other pkgs maint. don't agree, hance the user 
gets in trouble. 
And perhaps file bugrep, which perhaps get a WONTFIX since that maint 
doesn't agree with you.
Not cool.
 
> Having /var/run/ and /var/lock/ (as well as /tmp/) on tmpfs is a big
> advantage for laptops running on batteries, as well as stateless

maybe - depends on how often disk buffers are flushed. Normally using 
laptop-mode properly I see no significant difference. The bigger disk
stresser are loggers, usually.

> sysadmins will for now have to verify that all the packages they are
> using are able to cope with the options, but I hope in the future we
> can enable it by default for laptops and ltsp clients.

I think the disadvantages far offsets the advantages, till an agreement
is set between maintainers. I think no sysadmin is going to take the risk 
of having to fix all of +tens laptops on each apt-get upgrade for some
minutes more runtime (if any).
OTOH, one really determined to that, will setup fstab accordingly by hand
and is supposed to take charge of the issues, and know what he's doing.

Setup tmpfs by *install should be either disabled or preceeded by a BIG FAT
WARNING that doing so *will* break several pkgs. Then, once warned in 
advance, user can happily choose to shoot on his foot.
Till pkgs install/run policy is steered properly, that is.

thanks
--
paolo