interesting claims

From: Jeff <sysinit_at_yandex.com>
Date: Mon, 29 Apr 2019 21:19:58 +0200

i came across some interesting claims recently. on
http://skarnet.org/software/s6/
it reads

"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 ?
or is it true since s6-svscan already provides such respawn
capabilities ? ;-)

there is actually NO need for a "correct" working init implementation
to provide respawn capabilities at all IMO.
this can easily done in/by a subprocess and has 2 advantages:

- it simplyfies the init implementation

- process #1 is the default subprocess reaper on any unix
  implementation and hence a lot of terminated zombie subprocesses
  get assigned to it, subprocesses that were not started by it.
  if it has respawn capabilities it has to find out if any of this recently
  assigned but elsewhere terminated subprocesses is one of its
  own childs to be respawned. if it has lots of services to respawn
  this means lots of unnecessary work that could be also done
  in/by a suprocess aswell.

when do you kill a non supvervised process running with UID 0
"accidently" ? when calling kill ( -1, SIGTERM ) ?
the kernel protects special/important processes in this case from
being killed "accidently", that's true.
but where do we usually see that ? in the shutdown stage, i guess.
and that's exactly where one wants to kill all process with PID > 1
(sometimes excluding the calling process since it has to complete
more tasks). or when going into single user mode.

so this looks like a rather artificial and constructed argument for
the necessity of respawn functionality in an init implementation IMO.
Received on Mon Apr 29 2019 - 19:19:58 UTC

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