Hi!

Today in a Linux training a participant attempted to bring down Debian
workstation with Systemd by sending signals to PID 1 as I invited them
to try to bring down PID 1 while thinking for myself that this would not
be possible from my past experiences about trying to bring down PID 1 –
init – myself.

While sending SIGKILL to Systemd did not have any effect, sending SIGILL
– illegal instruction – to it brought the machine to an halt. I
reproduced it with

while true; do kill -ILL 1 ; echo -n "." ; sleep 0.5 ; done

on my training workstation (Debian 9.9 with Systemd 232 and 4.9.0-9
Debian Kernel with MDS mitigation).

The mouse pointer froze and the machine did not even respond to ping
anymore! According to participants about 4 to 5 times sending the signal
would be enough to bring down a workstation with Systemd as PID 1.

Despite all the bugs and issues I have seen or read about with Systemd I
was very surprised about that result.

Curiously I attempted the same with the Debian on my laptop that I
switched to SysVInit and elogind. As the elogind stuff mostly works I
think I will switch it to Devuan once I come around to it.

I am able to run

while true; do kill -ILL 1 ; echo -n "." ; done

against SysVinit's "init" process without any issue for minutes (Debian
Sid with sysvinit 2.93-8 and self-compiled 5.1.2 kernel, also with MDS
mitigation). It is even running while I write this mail normally now.

Also the participants found in the manpage kill(2):

NOTES
       The  only  signals  that  can be sent to process ID 1, the init
       process, are those for which init has explicitly installed sig‐
       nal handlers.  This is done to assure the system is not brought
       down accidentally.

So if that is actually true, then it appears that Systemd initiates a
signal handler for SIGILL for whatever reason.

I pondered about writing a bug report to Systemd developers, but
honestly from my past experiences with upstream feedback about bug
reports regarding Systemd I then decided not to bother about it. I am
not willing to take in and deal with any more "this is by design, go
away" or "this works as intended, go away" kind of responses. I am not
interested in Systemd to a larger extent than teaching participants of
my training what they need to know about it, when they have to deal with
it due to distribution choices made at their employer. And yes, I also
have a slide that summarizes critique about it, complete with links, so
they can make up their own opinion. And no, for me it is not black and
white, but my own decision is to go without Systemd.

This is another reason for me to start to provide Devuan VMs in the
Proxmox VE environment I use to provide VMs of various distributions to
the participants of my trainings. So participants can have a look at it
and do exercises with it if they like. I already started to incorporate
information about Devuan in some of my slides.

I share it here not to invite another bashing about Systemd, we really
do not need to go there, but instead can focus on strengthening the
alternatives. But I share it here to provide another reason to use a
Systemd-free distribution like Devuan. I also share it as an example of
the robustness of the SysVInit init process!

Thanks,
--
Martin