[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /run vs. /lib/run



On Thu, Dec 22, 2005 at 09:58:37AM +0000, Miquel van Smoorenburg wrote:
> In article <[🔎] 20051222064207.GC6455@localhost.localdomain>,
> Anthony Towns  <aj@azure.humbug.org.au> wrote:
> >On Thu, Dec 22, 2005 at 01:37:11AM +0000, Miquel van Smoorenburg wrote:
> >> This works at least on 2.6. [...]
> >> This means that /var/run is always writable.
> >That's really quite nice. I wonder if requiring 2.6 is even much of a
> >problem -- 2.6.0 came out two years ago already and will be three by
> >the time etch is released, after all; and I assume the Hurd can deal
> >with this sort of issue trivially.
> Well, it appears there's MS_MOVE support in 2.4 too, since 2.4.19.

Dude, so it does! Though in that case the mount manpage is wrong :-/

> >If "tmpfs swaps out" isn't enough to deal with screen and similar apps's
> >use of /var/run, it might be worth just moving them to /var/lib anyway.
> Well actually, perhaps we should not even use mount --move. Just
> copying the files is enough:

That doesn't work if some app keeps the file open while /var is being mounted
though.

> I tested this and it works fine. It's also a better solution, since
> several packages contain directories in /var/run and ofcourse
> they expect them to still exist after a reboot.

I suppose that's true; but where's the difficulty in just initialising
/var/run on mount from some template for the programs that need it?

> The only thing is - this won't work for Debian/kFreeBSD. Someone
> needs to write MS_MOVE support for the kFreeBSD kernel, I guess :)

Can't kFreeBSD do transparent mounts anyway, and just mount a real
/var/run over the top of a tmpfs, leaving the tmpfs still visible?

On Thu, Dec 22, 2005 at 05:15:32AM -0600, Peter Samuelson wrote:
> [Miquel van Smoorenburg]
> > I tested this and it works fine. It's also a better solution, since
> > several packages contain directories in /var/run and ofcourse they
> > expect them to still exist after a reboot.
> That's a bug, IMO - they should mkdir -p in their init scripts if
> necessary.  It's not like that's hard to do.

crack and crack-md5 are the only packages that include it in the deb;
the others already do it from the app, init script or postinst. But
we need to support third party apps too; so some special handling's
probably worthwhile.

Cheers,
aj

Attachment: signature.asc
Description: Digital signature


Reply to: