Hi Santiago,
Quoting Santiago Vila (2024-10-16 21:44:21)
> failed to create symlink /dev/fd at /usr/libexec/sbuild-usernsexec line 384.
> E: ABORT: Received PIPE signal (requesting cleanup and shutdown)
> E: apt-helper failed
> E: Failed to explain bd-uninstallable
>
> Sorry not to be more specific, as the failure happens randomly. I asked Jochen
> and he suggested that I should report this here.
>
> Line 384 in context:
>
> 369 for my $link (
> 370 ["/dev/fd", "/proc/self/fd"],
> 371 ["/dev/stdin", "/proc/self/fd/0"],
> 372 ["/dev/stdout", "/proc/self/fd/1"],
> 373 ["/dev/stderr", "/proc/self/fd/2"],
> 374 ["/dev/ptmx", "/dev/pts/ptmx"],
> 375 ["/dev/ptmx", "/dev/pts/ptmx"]
> 376 ) {
> 377 my ($link, $target) = @{$link};
> 378 if (-l "$rootdir/$link") {
> 379 unlink "$rootdir/$link" or die "cannot unlink $link";
> 380 }
> 381 if (-e "$rootdir/$link") {
> 382 unlink "$rootdir/$link" or die "cannot unlink $link";
> 383 }
> 384 symlink $target, "$rootdir/$link"
> 385 or die "failed to create symlink $link";
> 386 }
>
> What could be a good reason for the symlink in line 384 to fail?
>
> Funny detail: Some of my autobuilders have 1 CPU and others have 2 CPUs.
> As of today, I only have messages like the above from machines
> with 2 CPUs. Maybe it's a coincidence, or maybe not.I have not yet a theory why this could happen. The problem was probably there before already but it never caused issues because the unshare backend before my refactor was a shell script without "set -e" so it would just ignore any failures to create the symlink. To maybe get to the bottom of this I created a MR which makes symlink creation non-fatal but emits hopefully helpful warning messages to figure out what is going on: https://salsa.debian.org/debian/sbuild/-/merge_requests/90 Even if we don't figure it out, with this change you at least can build your packages without sbuild dying on you. :) Thank you for your bug report! cheers, josch
signature.asc
Description: signature
