Hi Luca, On Sun, May 19, 2024 at 06:04:38PM +0100, Luca Boccassi wrote: > On Sun, 19 May 2024 18:42:17 +0200 Helmut Grohne <hel...@subdivi.de> > wrote: > > the init process should handle SIGTERM more like an init system would > handle that > > This seems the obvious answer to me. sbuild is setting up a system such > that its component runs as pid1, so it needs to behave like a pid1. We > know this is special and requires supporting a number of interfaces. If > a program doesn't, then it shouldn't be running as pid1 in a namespace.
Die you mean "... so it needs to behave like a systemd"? sysvinit does not document SIGTERM as a supported signal. https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html Neither does runit. https://manpages.debian.org/bookworm/runit/runit.8.en.html#SIGNALS Nor did upstart. https://sources.debian.org/src/upstart/0.6.6-1/init/main.c/#L249 Or dumb-init (forwards all signals to its children). Or tini (forwards all signals to its children). https://github.com/krallin/tini/blob/master/src/tini.c#L525 Or busybox (see busybox init --help). But openrc-init and it then performs a shutdown. https://sources.debian.org/src/openrc/0.54-2/src/openrc-init/openrc-init.c/#L210 As far as my research goes, this handling of SIGTERM is specific to systemd and not a generic assumption of pid1. Helmut
