Re: interesting claims
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:
further claims
At http://skarnet.org/software/s6/why.html one can find further interesting claims: > The runit process, not the runsvdir process, > runs as process 1. This lengthens the supervision chain. haven't you claimed process #1 should supervise long running child processes ? runit fulfils exactly this requirement by supervising the supervisor. this simplifies both (runit-)init (it has only to compare the PIDs of terminated child processes with exactly 1 PID) and the supervisor runsvdir (the latter can do its usual business without the requirement to do process #1 specific work such as reacting to signals in a special way, running the 3 different init stages etc. one could also rightfully point out here that these are proces #1 specific tasks and not a supervisor's duties per se.). this lengthens the supervision chain but also has the additional advantage of a supervised supervisor. ;-) maybe runsvdir was not made to run as process #1 and this was just a hack its author came up with to replace (SysV) init totally. who knows ? but it works well (except that runit-init looks at /etc/runit/reboot etc after receiving SIGCONT which is no good idea at all since it requires unnecessary read-write access to the fs this files reside on. how about just reacting to signals, say use STGTERM to poweroff, SIGHUP to reboot, SIGUSR1 to halt, SIGUSR2 to reboot or poweroff and make signal handling scripts like /etc/runit/ctrl-alt-del etc just send one of those signals to process #1 when SIG(INT,WINCH) were received ? does not require any read-write fs access and looks much simpler to me.) "Artistic considerations": > runit has only one supervisor, runsv, for both a daemon and its logger. > The pipe is maintained by runsv. If the runsv process dies, the pipe > disappears and logs are lost. So, runit does not offer as strong a > guarantee as daemontools. sure, if (s6-)svscan dies one is in deep shit aswell, so what is the point here ? runsv gets restarted by runsvdir but the pipe is gone (are pipes really closed when the opening (parent) process exits without closing them itself and subprocesses still use that very pipe ?) > daemontools' svscan maintains an open pipe between a daemon and its logger, > so even if the daemon, the logger, and both supervise processes die, > the pipe is still the same so no logs are lost, ever, unless svscan itself > dies. but: > perp has only one process, perpd, acting both as a "daemon and logger > supervisor" (like runsv) and as a "service directory scanner" (like runsvdir). > It maintains the pipes between the daemons and their respective loggers. > If perpd dies, everything is lost. same for (s6-)svscan here (at least for the pipes). > however, perpd is well-written and has virtually no risk of dying. the same holds probably for (s6-)svscan, i guess. > Since perpd cannot be run as process 1, > this is a possible SPOF for a perp installation but from a design perspective it seems as reliable as s6-svscan ? or not since it uses a more integrated desing/approach ? this design simplifies communication since tasks are not implemented in other tools running as its (direct) subprocesses. so all kinds of fifos/pipes used for IPC are not necessary anymore except one socket per perpd process for client connections and there is no need for further communication with subprocesses (except via signals).
interesting claims
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.
