Hi Santiago, Quoting Santiago Vila (2024-11-17 21:19:42) > Using the latest sbuild, I'm getting this in some failed build logs: > > Purging /build/reproducible-path > Not cleaning session: cloned chroot in use > E: 10mount: umount: > /run/schroot/mount/trixie-file-c2b83387-2e15-4f1c-b04d-03a1f557313e: target > is busy. > E: 10mount: rmdir: failed to remove > '/var/run/schroot/mount/trixie-file-c2b83387-2e15-4f1c-b04d-03a1f557313e': > Device or resource busy > E: trixie-file-c2b83387-2e15-4f1c-b04d-03a1f557313e: Chroot setup failed: > stage=setup-stop > Chroot cleanup failed > E: Build failure (dpkg-buildpackage died) > > This used to happen a long time ago when I was using a mix of chroot backends, > including directory-based, overlayfs, and overlayfs + eatmydata. > > It has not happened ever again (which I know) after I switched to > file-based schroot backend. > > And now apparently it's happening again with the file-based schroot backend. > > Can you think of a reason why the switch to "/build/reproducible-path" make > this > more likely to happen? > > May a process not killed properly from one build affect the next build > in the same autobuilder? That would be my main concern.
I don't know enough about how schroot works to answer the last question. Jakob
Haufe (in CC) is responsible for the schroot backend in sbuild and might know
more.
Is the problem reproducible or random?
If it's reproducible, maybe it's possible to bisect sbuild between the last
version that worked and this version?
Can you maybe get more information on what is still utilizing the mountpoint
using lsof or similar mechanisms?
This reminds me of a problem I had recently (this August) with mmdebstrap where
a process (I think it was apt) was hogging the /dev/null mount longer than it
should via a zombie process. This Perl code took care of the issue in
mmdebstrap:
if (waitpid(-1, POSIX::WNOHANG) >= 0) {
info "waiting for background processes to finish...";
}
while ((my $child = waitpid(-1, 0)) > 0) {
my $status = $? >> 8;
info "PID $child exited with exit code $status";
}
Another thing you could try is to see if maybe this only happens with unstable
chroot but not with bookworm chroots. That would point to something in unstable
having changed (apt?).
Thanks!
cheers, josch
signature.asc
Description: signature
