supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Jeff <sysinit@yandex.com>
To: supervision <supervision@list.skarnet.org>
Subject: what init systems do you use ?
Date: Fri, 03 May 2019 02:53:21 +0200	[thread overview]
Message-ID: <15692301556844801@iva7-b6ed732000ae.qloud-c.yandex.net> (raw)
In-Reply-To: <emec0adab0-570f-4eae-844c-e68cba21d4e0@elzian>

thanks for the interesting links.

> https://www.reddit.com/r/linux/comments/2dx7k3/s6_skarnetorg_small_secure_supervision_software/cjxc1hj/?context=3

nice exchange of arguments.

> Do not mistake causes for consequences. Things are not correct
> because s6 does them; s6 does things because they are correct.

well i thought it inherited that behaviour from daemontool's svscan.
no i understand that this was a totally wrong assumption. :PP

> Then you are free to use one of the many incorrect inits out there,
> including sinit, Rich Felker's init, dumb-init, and others. You are
> definitely not alone with your opinion.

i wrote such an init myself which did a bit more than the ones you mention.
it ran REALLY fast. the only thing that was slow was my usage of
a customized (older) version of OpenRC (since i have written some own
openrc scripts (adding perp "support" et al) and am too lazy to write my
own scripts currently).

> However, you sound interested in process supervision

indeed. it's just a question of where to put the supervisor.

> if you subscribe to that idea, then you
> will understand why init must supervise at least 1 process.

ok, i understand your arguments and of course there is something
true about it.

> Maybe you've never bricked a device because init didn't respawn
> anything.

well, i bricked my desktop when doing init experiments.
but almost immediatly after hosing the system it comes into my
mind what exactly went wrong and i fix this on reboot.

i was forced to reboot from a rescue dvd only once so far. ;-)
(when testing "ninit" which i don't recommend)
and it involved only mounting the root fs on disc rw and fixing
some symlinks in /sbin (init et al), so this was no real problem
so long as one has console access.

that's why i wrote (/sbin/)testinit that forks, execs into the real init
to test in process #1 and sleeps a while in the child process
after which it kill()s process #1 with given signals.
this works usually very well and is safe to do.

> I have. The "rather artificial and constructed argument"
> happened to me in real life, and it was a significant inconvenience.

oh no, i hope it was not a remote server ... :-/
always try things out on a box you have console access to
or in a vm.

BTW:

what init systems do this list's subscribers use ?
i use statically linked (musl) BusyBox init (and gettys)
+ mksh (https://www.mirbsd.org/mksh.htm) + s6 + OpenRC
(v0.34.11, outdated) as default init system.
i also ran perp but now run everything to be supervised
under s6, started via a little setup shell script directly from
/etc/inittab (most "one time tasks" are indeed directly run
from the inittab file instead of a shell script).




  reply	other threads:[~2019-05-03  0:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-29 19:19 interesting claims Jeff
2019-04-30  2:49 ` Guillermo
2019-04-30  8:22 ` Laurent Bercot
2019-05-03  0:53   ` Jeff [this message]
2019-05-11 18:45     ` what init systems do you use ? 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=15692301556844801@iva7-b6ed732000ae.qloud-c.yandex.net \
    --to=sysinit@yandex.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).