Hi, I'm CC'ing 1075871, but if you you're the only maintainer I can add -quiet. Just let me know.
On Sat, Jul 06, 2024 at 11:30:04PM GMT, Johannes Schauer Marin Rodrigues wrote:
> Hi Charles (Carlos?),
Name is Carlos, nickname is Charles, usually everyone goes with the
nickname.
> Quoting Carlos Henrique Lima Melara (2024-07-06 22:34:45)
> > I was creating some chroots this past month and noticed it was taking
> > too long in the last step which is the update step. After a pretty
> > intense debugging session with sergiodj, we were able to pin down the
> > problem to a interaction between 3 things. Including gpg in the chroot,
> > the bump in the max number of file descriptors and this update step only
> > doing a chroot without mounting /proc - and not using sbuild-update,
> > which does not show this bahaviour.
> >
> > It basically boils down to gpg-agent trying to close all the possible
> > file descriptors when it's running. This happens because this is the
> > fallback behaviour when /proc is not mounted. When it is mounted, it
> > just closes what is showed in /proc/<pid>/fd/. This always happened, but
> > with the increase of the max number of fds [1], it's really taking a
> > loooong time to finish sbuild-createchroot.
>
> this sounds like a bug but how is it a bug in sbuild-createchroot? The tool is
> just a very thin wrapper around debootstrap and the issue will also appear in
> debootstrap, no?
Yes, it's a thin wrapper (I think, don't speak perl, sorry). But the
problem is the last step where it chroot (plain chroot, nothing fancy)
to do an apt update. There it just invoke chroot but don't mount /proc
inside the chroor and then this triggers the fallback behaviour of
gpg-agent (exhaustively closing fds on a fork). It's the following
section of sbuild-createchroot that do the update [1]:
if (!$conf->get('SETUP_ONLY') || !$conf->get('MAKE_SBUILD_TARBALL')) {
# FIXME: also update packages with the unshare backend
if ($conf->get('ARCH') eq $conf->get('HOST_ARCH') &&
$conf->get('CHROOT_MODE') ne 'unshare') {
my $session = Sbuild::ChrootPlain->new($conf, $target);
my $host = Sbuild::ChrootRoot->new($conf);
if (defined($session)) {
$session->set('Log Stream', \*STDOUT);
if (!$session->begin_session() || !$host->begin_session()) {
print STDERR "E: Error creating chroot session: skipping apt
update\n";
} else {
my $resolver = Sbuild::AptResolver->new($conf, $session, $host);
$resolver->setup();
In sbuild-update, it begins a new schroot source session with sbuild -
and here sbuild/schroot mounts /proc so gpg-agent use it to only close
the open fds. That's the main difference between sbuild-update and
sbuild-createchroot's update step.
> Also, why are you using sbuild-createchroot? Are you trying to set up the
> initial schroot configuration?
Yes, to create a schroot to use with sbuild. Mainly as a convenience
script instead of using debootstrap.
> Why is this not a bug in gpg-agent?
Because it has the code to close file descriptors in a smart way (using
/proc/<pid>/fd) which is the preferred way.
Hopefully I could clarify things for you.
> cheers, josch
Cheers,
Charles
[1]
https://salsa.debian.org/debian/sbuild/-/blob/main/bin/sbuild-createchroot#L676
signature.asc
Description: PGP signature
