Re: interesting claims

From: fungal-net <>
Date: Sat, 18 May 2019 16:26:00 +0000

The tests I did were on live images run as vm-s

> 18.05.2019, 00:58, "Guillermo" <>:
>>>  OpenRC: Nice,
>>>    init
>>>     |_ zsh
>>>    when I exited the shell there was nothing but a dead cursor on my screen
> in this case the shell is not signaled since "-1" does not signal the sending
> process.
>> May I ask what was this setup like? You made a different entry for
>> sysvinit, presumably with the customary getty processes configured in
>> /etc/inittab 'respawn' entries, judging by your results, so how was
>> the OpenRC case different?
> i also wondered whether he used openrc-init here ?
> in that case he may have also used openrc's "supervise-daemon" util
> which do not get restarted after they were terminated by the kill -1 -9
> blast and hence cannot respawn the gettys. looks like you were pretty
> hosed when you quit the super-user zsh (which sent the kill blast via
> its "kill" builtin) ?

I remember seeing this although I may have mixed it up. I have a few
Artix-OpenRC images and an older Manjaro-OpenRC which was a predecessor.
 Running both again didn't produce this result. They just froze with a
dash on the top left of the screen, didn't poweroff. So I am puzzled now
what I mixed up.

> you should provide more information on the used init here as openrc
> is not an init per se and works well with sysv + busybox init, runit, ...

This is clearly the case of OpenRC in some early Refracta images I have,
I didn't use them. The Devuan version of OpenRC works as an additional
service supervisor. In Artix if there are sysv type of scripts must be
limited in the early parts of booting.

>>>  sysV: init and 6 ttys with shell ... nothing can kill it that I know off.
> what do you mean here ?
> were the gettys respawned by SysV init or did they not die at all ?
> where did you send the signal from ?
> i would assume from a super-user zsh on a console tty ?

I am pretty sure I used a Devuan/Miyo image on this one, and I am pretty
sure they were respawned time after time of trying it again, as pids
were higher numbered.

For runit I used one Artix and one void, they seem to behave the same.

But although I got curious what "kill -9 -1" would do to different
systems I don't see the usefulness of this. What could possibly,
without intention, do such a thing to a system? An
intruder/virus/trojan trying to mess up your system? I can't see that
software would malfunction to do something like this.

My initial inquiry was what it would be like killing things and going
down to 1 and whether you can rebuild from there, still a tty is needed,
or an ssh serving daemon to access such system. And this is only just
reversing stage 2, right?
Received on Sat May 18 2019 - 16:26:00 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC