Hi, steps to reproduce:
Hi josch, * Johannes Schauer Marin Rodrigues <josch@debian.org> [2023-11-22 07:22]: The difference is due to mmdebstrap opening a extra namespace here: https://sources.debian.org/src/mmdebstrap/1.4.0-1/mmdebstrap/#L1707 I tried to adding an unshare --mount to sbuild here but did not manage: https://sources.debian.org/src/sbuild/0.85.4/lib/Sbuild/ChrootUnshare.pm/#L324 Maybe you have an idea where to put it? While at it I also researched a bit into ischroot: # How does ischroot work: ischroot assumes that a chroot changes the mountinfo file and that the one of PID 1 is not chrooted. This is true for a chroot set up by schroot for example. sbuild+unshare instead also mounts a new proc and thus it is becoming PID 1, or rather the runuser in ChrootUnshare.pm. So one way around this would be to mount the outside proc, as in: - mount -t proc proc \"\$rootdir/proc\"; + mount -o rbind /proc \"\$rootdir/proc\"; in: https://sources.debian.org/src/sbuild/0.85.4/lib/Sbuild/ChrootUnshare.pm/#L323 But that means that the package build in sbuild can list outside processes which seems suboptimal. # How is ischroot used I looked at the results at: https://codesearch.debian.net/search?q=ischroot And it is used rather seldom (besides some testing code): https://codesearch.debian.net/search?q=ischroot+package%3A%5CQdebootstrap%5CE https://codesearch.debian.net/search?q=ischroot+package%3A%5CQglibc%5CE https://codesearch.debian.net/search?q=ischroot+package%3A%5CQsysvinit%5CE https://codesearch.debian.net/search?q=ischroot+package%3A%5CQcdist%5CE https://codesearch.debian.net/search?q=ischroot+package%3A%5CQmini-buildd%5CE mini-buildd btw. also uses systemd-detect-virt as an alternative (though not with --chroot). And there is at least one package that does the same as ischroot manually: https://codesearch.debian.net/search?q=ischroot+package%3A%5CQsalt%5CE On the other hand it considered second-class in debianutils: https://sources.debian.org/src/debianutils/5.14/CONTRIBUTING/?hl=28#L28 So maybe it should be replaced by systemd-detect-virt but that compares the inodes of /proc/1/root and / which seems even more brittle as /proc/1/root is not readable by everyone and seems to have the same issues as ischroot, otherwise. # telinit behaviour From #debian-bootstrap I understood that this is actually an issue during cross compiling something when `libc6.postinst configure` is called resulting in an endless loop of telinit. There are two implementations of telinit in Debian. The one in sysvinit-core does not seem to trigger this behaviour, whereas the one in systemd-sysv does seems to wait forever. On the other hand telinit(8) from systemd-sysv states that it should not be used anymore. So maybe libc6.postinst should use a different interface and/or do something else to check if PID 1 is actually an init? Or should sbuild run some init as PID 1? Cheers Jochen
Hi, Quoting Jochen Sprickerhof (2023-11-24 13:06:31) this is is only invoked for --chrooted-*-hooks but CLONE_NEWNS is also what mmdebstrap unshares by default here: https://sources.debian.org/src/mmdebstrap/1.4.0-1/mmdebstrap/#L535 This is already done here: https://sources.debian.org/src/sbuild/0.85.4/lib/Sbuild/ChrootUnshare.pm/#L279 What made you think that CLONE_NEWNS was responsible? It should be unshared for both sbuild and mmdebstrap hooks. Yes, lets not do this. ischroot also compares the ino and dev of / and /proc/1/root: https://sources.debian.org/src/debianutils/5.14/ischroot.c/#L153 Since the problem does not happen with mmdebstrap, I think this might just be a bug in sbuild. I also suspect that your thoughts about PID 1 go into the right direction because sbuild and mmdebstrap set up the unshared processes slightly differently. Look at the complex dance of processes that mmdebstrap does: https://sources.debian.org/src/mmdebstrap/1.4.0-1/mmdebstrap/#L486 no, sbuild should definitely not run any init. I also don't know of a reliable way to distinguish a process that is PID 1 from being an "init" or not. The workaround I've used to get around this bug in sbuild was to just not create a buildd chroot that includes systemd-sysv. I only saw this bug because I wrongly created my buildd chroots without passing --variant to mmdebstrap and the default variant includes systemd-sysv hence triggering this bug. Also, even if this is a bug in telinit from systemd-sysv, I want this bug to be about ischroot not reporting the right thing when run from inside a build process. I think this is a considerable bug in sbuild's unshare mode. Thanks a lot for your investigation! cheers, josch
* Johannes Schauer Marin Rodrigues <josch@debian.org> [2023-11-24 20:57]: Ah, I only tested with your: I think it is due to mmdebstrap having extra process and maybe doing the CLONE_NEWNS in a different process? I think that is part of why it works with mmdebstrap. Compare: $ sbuild -d unstable --starting-build-commands='ps auxf' --add-depends=procps hello USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 4536 2816 ? S+ 20:17 0:00 /sbin/runuser -u root -- sh -c cd "$1" && shift && "$@" -- /build/package /bin/sh -c ps auxf root 41 0.0 0.0 2580 1408 ? S+ 20:17 0:00 sh -c cd "$1" && shift && "$@" -- /build/package /bin/sh -c ps auxf root 42 0.0 0.0 2580 1408 ? S+ 20:17 0:00 \_ /bin/sh -c ps auxf root 43 0.0 0.0 8116 4096 ? R+ 20:17 0:00 \_ ps auxf and: $ mmdebstrap --chrooted-customize-hook='ps auxf' --variant=essential --include=procps unstable /dev/null USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.5 0.1 32616 25252 ? S+ 20:15 0:00 /usr/bin/perl /usr/bin/mmdebstrap --chrooted-customize-hook=ps auxf --variant=essential --include=procps unstable /dev/null root 1716 0.0 0.1 32616 23956 ? S+ 20:15 0:00 /usr/bin/perl /usr/bin/mmdebstrap --chrooted-customize-hook=ps auxf --variant=essential --include=procps unstable /dev/null root 1717 0.0 0.0 2580 1536 ? S+ 20:15 0:00 \_ sh -c ps auxf root 1718 0.0 0.0 8116 3968 ? R+ 20:15 0:00 \_ ps auxf And note that for mmdebstrap PID 1 has a different mountinfo as PID 1716 and below. Cheers Jochen
Hi josch, I can no longer reproduce this problem and my trixie sbuild returns "is chroot". Can you close this if you agree? Cheers Jochen * Jochen Sprickerhof <jspricke@debian.org> [2023-11-24 21:24]: