[Pkg-sysvinit-devel] Re: Supporting tmpfs on /var/run

[Henrique de Moraes Holschuh]

On Tue, 03 Jan 2006, Miquel van Smoorenburg wrote:
> On Tue, 2006-01-03 at 15:34 +0100, Thomas Hood wrote:
> > We need to make a decision about whether and how to support initialization of
> > /var/run.  The options are:
> > 
> >    0. Don't initialize /var/run at all.  If packages need subdirs or initial files
> >       in /var/run then they create them in initscripts or elsewhere.
> > 
> >    1. Copy a skeleton dir to /var/run.  I'd suggest something like this:
> > 
> >             cp -a /etc/init-skeleton/var/run/* /var/run
> > 
> >       which could be extended for use elsewhere, e.g.,
> > 
> >             cp -a /etc/init-skeleton/run/* /run
> > 
> >    2. Use dpkg-statoverride as described here:
> > 
> >             http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2005-December/000295.html
> > 
> > As things stand now, I prefer #1 and hmh prefers #2.  So someone else will have
> > to break the tie.  :)
> 
> Sorry. If we go with /run, then /var/run can be on normal disk, and in
> that case I prefer #0. In the case of 'early /var/run' /var/run needs to
> be on a tmpfs. Then I prefer #1, because it looks like #2 would add
> significant startup delay.

#0 can also potentially involve calls to dpkg-statoverride inside the
initscripts if they are prepared for an ephemeral /var/run.  Since this is
exactly what we are talking about, I think we should assume /var/run is
tmpfs OR rm -rf'ed right after it is mounted for this thread.

If we want #0 not to use dpkg-statoverride unless [maybe if] it is a leaf
initscript (i.e. one nobody will depend on), we better document that
somewhere.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh