supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Guillermo <gdiazhartusch@gmail.com>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: interesting claims
Date: Sat, 18 May 2019 17:04:21 -0300	[thread overview]
Message-ID: <CADQ2Nw9Zw63ns4ejdTODrYRBpjkb1XTteoCYgmgXurZZFtr2Lg@mail.gmail.com> (raw)
In-Reply-To: <57af526d-cc12-135b-218c-721d51129876@obarun.org>

El sáb., 18 may. 2019 a las 13:26, fungal-net escribió:
>
> >>>  OpenRC: Nice,
> >>>    init
> >>>     |_ zsh
> >>>    when I exited the shell there was nothing but a dead cursor on my screen
> > [...]
> >> 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 ?
> > [...]
> 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.

Ah, the OpenRC variant of Artix. That might explain it. Apparently,
this does mean 'pure' OpenRC indeed, i.e. openrc-init and
openrc-shutdown in addition to the service manager. I didn't know
there were distributions that used this setup.

openrc-init, just like Suckless init, does not currently supervise any
other process, so this test seems to have put the VM in a coma by
killing every process but #1 (after the only apparent survivor, zsh,
exited).

> But although I got curious what "kill -9 -1" would do to different
> systems I don't see the usefulness of this.

Since you actually went ahead and did it, and reported the results,
for me it was interesting to see if they matched what theory says that
would happen. They did (assuming that what you wrote about the s6 case
means that the system more or less reconstructed itself).

Thanks,
G.


  reply	other threads:[~2019-05-18 20:04 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
2019-05-18 20:04                       ` Guillermo [this message]
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=CADQ2Nw9Zw63ns4ejdTODrYRBpjkb1XTteoCYgmgXurZZFtr2Lg@mail.gmail.com \
    --to=gdiazhartusch@gmail.com \
    --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).