On Wed, Mar 30, 2011 at 11:20:45PM +0100, Roger Leigh wrote: > On Wed, Mar 30, 2011 at 10:32:51PM +0200, Goswin von Brederlow wrote: > > Tollef Fog Heen <tfheen@err.no> writes: > > > > > ]] Julien Cristau > > > > > > | On Wed, Mar 30, 2011 at 16:20:10 +0100, Roger Leigh wrote: > > > | > > > | > Given that Fedora are adopting /run, and it has been something > > > | > we have wanted in the past, is anyone working on implementing > > > | > /run in Debian? > > > | > > > > | > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 > > > > > > Incidentially, I just sent a mail proposing this as a release goal. > > > > > > | That seems to say "on Debian /lib/init/rw was introduced for the same > > > | thing, but I'm using a different name just because I can". What am I > > > | missing? > > > > > > It's a bit of an abuse of the /lib namespace. It also outlines a plan > > > for how to get rid of /var/run and /var/lock long-term, something I > > > don't believe /lib/init/rw ever tried to. It was just somewhere to > > > stuff random early data. > > > > What subdirs will we have then? > > > > /run/run (formerly /var/run) > > /run/init (formerly /lib/init/rw) > > /run/lock (formerly /var/lock) > > > > or will one of the formerlies become the /run and the other subdirs. or > > will /var/run and /lib/init/rw be merged into just /run and /run/lock > > for locks? > > I've filed a bug (#620191) against initscripts containing a proposed > patch for this. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620191 > > /var/run (→ /run) > /var/lock (→ /run/lock) > /lib/init/rw (→ /run/init) OK, an update on progress implementing /run: Patches filed against base-files and initscripts in #620157 and #620191. Test packages here: http://people.debian.org/~rleigh/run/ (tested in an amd64 kvm VM; it shouldn't toast your system by making it unbootable, but YMMV; test with caution.) There's a couple of outstanding issues which I could use some help with: 1) /etc/init.d/mountall.sh is broken for some reason. The "mount -a" invocation fails. Not because it fails to mount, but it returns a 32 exit status because / and /proc are already mounted. Possibly a result of the mtab.sh domtab() changes; but it should be behaving identically to the old version, so possibly unrelated. Possibly already broken and I've just exposed a bug? 2) Despite only mounting /run once, I'm seeing /run and /run/lock mounted *again* looking at /proc/mounts. Unsure why this happens, or if it's just artifactual. /run, /run/lock and /run/init are all correctly visible, but this is a tad strange. I would also appreciate any testing, especially if you're using a nonstandard setup e.g. tmpfs on /var/run and/or /var/lock. This should be catered for. Testing on kfreebsd would also be welcome, since the mtab changes were done to make bind mounting work for it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature