On Mon, 20 May 2024 at 10:37, Aurelien Jarno <aure...@debian.org> wrote: > > On 2024-05-20 10:22, Luca Boccassi wrote: > > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > > <jo...@debian.org> wrote: > > > > > > Hi, > > > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > > * Johannes Schauer Marin Rodrigues <jo...@debian.org> [240520 07:35]: > > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > > more involved checks about what PID 1 is? It could then make sure to > > > > > only call > > > > > systemd telinit if systemd is pid 1. [..] > > > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > > telinit, and a specific telinit, into a ton of different things > > > > makes all those things hard to get right, hard to update, the usual. > > > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > > they are not that different. Both try to talk to their respective > > > > pid1 daemons first using their respective communication socket. > > > > > > > > But then, if that doesn't work, they diverge: > > > > - sysvinit's telinit just gives up > > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > > being in a chroot, before doing any of that. > > > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > > fallback to stick with sysvinit's behaviour? > > > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and > > > > glibc's > > > > postinst (and other places) can become simpler again. > > > > > > via irc, jochen also pointed out: telinit could be the component which > > > checks > > > what PID 1 actually is and only do its thing after it confirmed that it is > > > indeed an init system like systemd that is providing PID 1? > > > > That's all legacy stuff and I really don't want to touch it anymore. > > Going from the other side, maybe libc6.postinst could use something > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > out the situation a bit better? > > Nope.
What's the output? With SYSTEMD_LOG_LEVEL=debug exported
