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: Mon, 29 Apr 2019 23:49:24 -0300	[thread overview]
Message-ID: <CADQ2Nw_oBa_WEKeJxDCwWC42qOM1tqAEZ_kGsY8izKLOJhmHQg@mail.gmail.com> (raw)
In-Reply-To: <11997211556565598@myt6-27270b78ac4f.qloud-c.yandex.net>

El lun., 29 abr. 2019 a las 16:46, Jeff escribió:
>
> "suckless init is incorrect, because it has no supervision capabilities,
> and thus, killing all processes but init can brick the machine."
>
> a rather bold claim IMO !
> where was the "correct" init behaviour specified ?
> where can i learn how a "correct" init has to operate ?
> [...]
> there is actually NO need for a "correct" working init implementation
> to provide respawn capabilities at all IMO.

This was discussed in the mailing list, you'll be able to find
relevant messages in the archives, and the last part of the sentence
you quoted should clarify what "correct" means in this context. But to
recap:

* A failure mode is identified (the machine becomes unusable and
requires a hard reboot), along with the condition that triggers it
(death of all processes except #1).
* The condition can be triggered explicitly with a kill(-1, SIGKILL)
call in a process with root privileges, so by definition it is not an
impossible condition, but this is not the only way to trigger it.
Processes can die for a variety of reasons.
* An program with "respawn capabilities" running as process 1 can
avoid entering this failure mode, a program that does not have the
capabilities, cannot.

Nothing more, nothing less. This is not a statement about how likely
this failure mode is, only that it exists. An init system can or
cannot choose to prevent it, this is a design choice (and usage of
"correct" will give you an idea of what the author of this particular
software package thinks), and a person may or may not decide to use an
init system that doesn't, this is a matter of preference.

G:


  reply	other threads:[~2019-04-30  2:49 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 [this message]
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
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=CADQ2Nw_oBa_WEKeJxDCwWC42qOM1tqAEZ_kGsY8izKLOJhmHQg@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).