supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: fungal-net <fungalnet@obarun.org>
To: supervision@list.skarnet.org
Subject: Re: interesting claims
Date: Sat, 18 May 2019 16:26:00 +0000	[thread overview]
Message-ID: <57af526d-cc12-135b-218c-721d51129876@obarun.org> (raw)
In-Reply-To: <5994381558140755@sas2-2074c606c35d.qloud-c.yandex.net>

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

Jeff:
> 18.05.2019, 00:58, "Guillermo" <gdiazhartusch@gmail.com>:
>>>  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?



  reply	other threads:[~2019-05-18 16:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-29 19:19 Jeff
2019-04-30  2:49 ` Guillermo
2019-04-30  8:22 ` Laurent Bercot
2019-05-03  0:53   ` what init systems do you use ? Jeff
2019-05-11 18:45     ` Guillermo
2019-05-13 19:13     ` multiplexd
2019-05-13 20:36       ` Laurent Bercot
2019-05-13 21:09       ` Steve Litt
2019-05-14  2:34         ` Guillermo
2019-05-13 21:16       ` Joshua Ismael Haase Hernández
2019-05-14  5:50     ` Colin Booth
2019-05-14  7:15       ` eric vidal
2019-04-30  8:47 ` interesting claims Jonathan de Boyne Pollard
2019-05-01  7:26 ` Steve Litt
2019-05-01  7:33 ` Steve Litt
2019-05-01 18:13   ` Laurent Bercot
2019-05-15 17:22     ` Steve Litt
2019-05-15 23:22       ` Oliver Schad
2019-05-16  1:07         ` Steve Litt
2019-05-16  5:36           ` fungal-net
2019-05-16  8:32             ` Laurent Bercot
2019-05-16 17:10               ` Jeff
2019-05-17  0:23               ` Dewayne Geraghty
2019-05-17 11:21               ` fungal-net
2019-05-17 22:57                 ` Guillermo
2019-05-18  0:52                   ` Jeff
2019-05-18 16:26                     ` fungal-net [this message]
2019-05-18 20:04                       ` Guillermo
2019-05-19 11:24                         ` fungal-net
2019-05-19 12:57                           ` killall test run Jeff
2019-05-19 17:29                             ` Colin Booth
2019-05-19 20:39                             ` Guillermo
2019-05-19 23:06                               ` Laurent Bercot
2019-05-19 20:35                           ` interesting claims Guillermo
2019-05-03  1:37   ` how to handle system shutdown ? Jeff
2019-05-03 19:25     ` Laurent Bercot
2019-05-05  0:52       ` is it required to call kill() from process #1 ? Jeff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57af526d-cc12-135b-218c-721d51129876@obarun.org \
    --to=fungalnet@obarun.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).