On Mon, May 21, 2018 at 05:53:56PM +1000, wirelessd...@gmail.com wrote: > >> On Tue, 15 May 2018 23:39:24 +1000 > >> Tom <wirelessduck@???> wrote: > >> > >>> Thanks as always for your insightful information Steve. Much > >>> appreciated. As someone who knows very little about init systems, > >>> can you explain what this respawning business is all about? > >> > >> Terminology: I call the init system we've used for 30 years "sysvinit". > > > >> I assume here you mean sysvinit when you write sysv-rc. > > > > I think Tom is not referring to the whole init system, rather to just the > > rc scripts:
> Originally, I really had no idea what I was referring to specifically. > After some more poking around, I think you’re right. I said sysv-rc > because I noticed that installing the openrc package would only > uninstall/conflict with the sysv-rc package and not the rest of sysvinit. The important part is: sane init systems are _modular_. Various fields have various integration-to-modularity tradeoffs, and init+rc+supervisor schemes are at such an extreme that I say it would take a deranged mind to argue that an unextendable blob is fit for this job. The reason is: none of the contenders is adequate for every single use case, thus you need to allow the sysadmin to replace pieces with something that he/she wants. More importantly, "job security" is antithetical to Free Software: an irreplaceable tangle can't be reasonably improved. A set of small modules, on the other hand, is _made_ for experiments, many of which will take over their predecessors. Don't fear change, fear inability to change. Main parts here are: * init. Pid 1. Its tasks are: 1. spawning the rc system; 2. reaping orphaned processes. That's all. Other functionality might be also implemented in pid 1, but that's up to you -- for example, sysvinit chose to add a rudimentary process supervisor whose main use today is spawning getties -- and a particular contender put pretty much everything there. * rc system. On De??an started by /etc/init.d/rcS; its tasks are starting daemons whenever you boot, shutdown, switch to a different runlevel, install or remove a package, or otherwise manually request. This is sysv-rc or openrc. * daemon supervisor. This is what handles daemons that unexpectedly die. Most daemons are designed to not die, the only case on a regular Unix system is getty -- anything else tends to be a hallmark of an attack; usually mindlessly restarting turns a DoS into giving more and more opportunity of a successful intrusion. For a real supervisor you want something like runit; sysvinit has inittab which is extremely limited. OpenRC has no equivalent -- or rather, had none until the introduction of supervise-daemon which I don't know yet. But hey, it's not like I'm one of uploaders of openrc or anything to be supposed to know such things, am I? .sig related. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start ⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax ⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child: ⠈⠳⣄⠀⠀⠀⠀ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng