On Sun, May 15, 2011 at 07:25:19PM +0200, Jakub Wilk wrote:
Due to the advent of /run, I manually changed layout of my chroots,
so that they look like this:
$ ls -ld /srv/chroots/unstable-i386/{var,run}/lock
drwxrwxrwt 2 root root 4096 May 15 01:19 /srv/chroots/unstable-i386/run/lock
lrwxrwxrwx 1 root root9 May 15 14:59 /srv/chroots/unstable-i386/var/lock
- /run/lock
Unfortunately, sbuild is not happy with such a layout, and I cannot
build more than one package in parallel (even though I use cloned
chroots, so it should be possible). I get this message instead:
Another sbuild process (job zlib_1.2.3.4.dfsg-3, pid 5534 by user sbuild) is
currently using the build chroot; waiting...
It looks like sbuild uses /run/lock from the outside of the chroot.
When I changed the symlink to a relative one, the problem
disappeared.
Thanks for bringing this up. I think that, by default, initscripts
will leave the chroot /var/run and /var/lock in place, which implies
that they will be separate from the host unless you switch to using
/run with /var/run and /var/lock as symlinks (as you have done).
However, this won't be the case for newly-debootstrapped chroots once
base-files is updated.
I would certainly prefer to use relative symlinks--I took this up on
debian-policy last week. This is because relative symlinks between
top-level directories must be absolute according to section 10.5.
I'll certainly bring this issue to their attention.
sbuild could switch to using /run/lock directly. However... if it's
set up using the default scheme, it will be symlinked to /var/lock
which will again be the host's /var/lock.
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.
signature.asc
Description: Digital signature