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