Re: /run vs /var/run
On Saturday 24 December 2005 11:35, Goswin von Brederlow
> > Also as for sym-links, there's no reason why /var/run couldn't be used
> > all along. Imagine we have a system where /var is mounted from an LVM
> > volume (or something else that can't be mounted early on). So we start
> > with a /var mount-point which has a /var/run mount-point under it and we
> > mount our tmpfs there. We then use the --bind option of mount to have it
> > also mounted as /etc/run (or whatever). Then we have daemons started etc
> > which do things under /var/run without any modification to their previous
> > operation. When the real /var file system is mounted mount --bind or
> > --move is used to put the file-system back on /var/run from /etc/run.
> > Optionally we could have special-case code in the script that does mount
> > -a to have it umount /var/run first.
> Can't be umounted, files may be opened. And --move it just to have no
> /run dir is pretty silly.
What I am suggesting is that /var/run be mounted early, and mount --move be
used to temporarily move it aside while the real /var is mounted and then
mount --move to move it back afterwards. No need to umount.
> > I believe that this idea is significantly better than the /run
> > suggestion. It requires changing no other programs, gives the potential
> > of performance benefits (RAM being faster than disk) and system
> > reliability benefits on flash storage systems, and doesn't require
> > breaking the FHS.
> Basicaly everything that needs /run doesn't use /var/run anyway,
> e.g. mount. And one could link /var/run to /run on both / and /var and
> then nothing needs to change even if it uses /var/run.
You mean to say that nothing needs to change about from adding a new directory
that's not in the FHS.
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page