Re: interesting claims
El dom., 19 may. 2019 a las 8:24, fungal-net escribió: > > [...] > This is Adélie adelielinux.org > installation on HD. Although it is confusing to me how they set this up > still, after months of following its development (beta3), there is > sysvinit on the first steps of booting then OpenRC takes over, and then > s6-supervisor handles everything running. It is like a fruit punch in > my eyes. As far as I can tell, at the moment it has a sysvinit + OpenRC setup, plus an s6 supervision tree anchored to process #1. Unlike other distributions, the getty processes are part of the supervision tree, and placed there by an Adélie-specific OpenRC service in the sysinit runlevel. > One of the reasons I am trying to learn more about init in general and > porting s6 to a different system is to use either Adélie or Void-musl > and have pure s6 on them. I believe Adélie is heading towards supporting that. > Both s6/s6-rc and 66 pkgs are available through void's repositories but > s6-rc has been modified and I haven't been able to get it to work. Really? As far as I can tell, Void's s6-rc is the unmodified upstream package, and Void's 66 is the unmodified package from Obarun's repository. > Void uses arch-like /bin /sbin --> /usr/bin, Adélie has more traditional > 4 separate directories. Yeah, that's both /usr-merge and bin-sbin merge. A whole discussion in itself. G.
Re: interesting claims
Guillermo: >> But although I got curious what "kill -9 -1" would do to different >> systems I don't see the usefulness of this. > > Since you actually went ahead and did it, and reported the results, > for me it was interesting to see if they matched what theory says that > would happen. They did (assuming that what you wrote about the s6 case > means that the system more or less reconstructed itself). I am glad some of you can tell more than I can about this, and since you did I tried my weirdest of setups. This is Adélie adelielinux.org installation on HD. Although it is confusing to me how they set this up still, after months of following its development (beta3), there is sysvinit on the first steps of booting then OpenRC takes over, and then s6-supervisor handles everything running. It is like a fruit punch in my eyes. For those that don't know this is built on musl. # kill -9 -1 on tty1 brought me back to tty1 login screen with 5 more ttys active. So everything is respawned almost instantly to a system just like it had just booted. Doing the same from terminal on X had the same exact outcome. > Thanks, > G. One of the reasons I am trying to learn more about init in general and porting s6 to a different system is to use either Adélie or Void-musl and have pure s6 on them. Recent efforts with void failed, except for using arch kernel building and installing Obarun's pkgs into void. Not very clean but works for months. Dracut is a thing I still need to learn about as obstacle #1. Both s6/s6-rc and 66 pkgs are available through void's repositories but s6-rc has been modified and I haven't been able to get it to work. Void uses arch-like /bin /sbin --> /usr/bin, Adélie has more traditional 4 separate directories.
Re: interesting claims
The tests I did were on live images run as vm-s Jeff: > 18.05.2019, 00:58, "Guillermo" : >>> OpenRC: Nice, >>> init >>> |_ zsh >>> when I exited the shell there was nothing but a dead cursor on my screen > > in this case the shell is not signaled since "-1" does not signal the sending > process. >> May I ask what was this setup like? You made a different entry for >> sysvinit, presumably with the customary getty processes configured in >> /etc/inittab 'respawn' entries, judging by your results, so how was >> the OpenRC case different? > > i also wondered whether he used openrc-init here ? > in that case he may have also used openrc's "supervise-daemon" util > which do not get restarted after they were terminated by the kill -1 -9 > blast and hence cannot respawn the gettys. looks like you were pretty > hosed when you quit the super-user zsh (which sent the kill blast via > its "kill" builtin) ? I remember seeing this although I may have mixed it up. I have a few Artix-OpenRC images and an older Manjaro-OpenRC which was a predecessor. Running both again didn't produce this result. They just froze with a dash on the top left of the screen, didn't poweroff. So I am puzzled now what I mixed up. > you should provide more information on the used init here as openrc > is not an init per se and works well with sysv + busybox init, runit, ... This is clearly the case of OpenRC in some early Refracta images I have, I didn't use them. The Devuan version of OpenRC works as an additional service supervisor. In Artix if there are sysv type of scripts must be limited in the early parts of booting. > >>> sysV: init and 6 ttys with shell ... nothing can kill it that I know off. > > what do you mean here ? > were the gettys respawned by SysV init or did they not die at all ? > where did you send the signal from ? > i would assume from a super-user zsh on a console tty ? I am pretty sure I used a Devuan/Miyo image on this one, and I am pretty sure they were respawned time after time of trying it again, as pids were higher numbered. For runit I used one Artix and one void, they seem to behave the same. But although I got curious what "kill -9 -1" would do to different systems I don't see the usefulness of this. What could possibly, without intention, do such a thing to a system? An intruder/virus/trojan trying to mess up your system? I can't see that software would malfunction to do something like this. My initial inquiry was what it would be like killing things and going down to 1 and whether you can rebuild from there, still a tty is needed, or an ssh serving daemon to access such system. And this is only just reversing stage 2, right?
Re: interesting claims
18.05.2019, 00:58, "Guillermo" : >> OpenRC: Nice, >> init >> |_ zsh >> when I exited the shell there was nothing but a dead cursor on my screen in this case the shell is not signaled since "-1" does not signal the sending process. > May I ask what was this setup like? You made a different entry for > sysvinit, presumably with the customary getty processes configured in > /etc/inittab 'respawn' entries, judging by your results, so how was > the OpenRC case different? i also wondered whether he used openrc-init here ? in that case he may have also used openrc's "supervise-daemon" util which do not get restarted after they were terminated by the kill -1 -9 blast and hence cannot respawn the gettys. looks like you were pretty hosed when you quit the super-user zsh (which sent the kill blast via its "kill" builtin) ? you should provide more information on the used init here as openrc is not an init per se and works well with sysv + busybox init, runit, ... >> sysV: init and 6 ttys with shell ... nothing can kill it that I know off. what do you mean here ? were the gettys respawned by SysV init or did they not die at all ? where did you send the signal from ? i would assume from a super-user zsh on a console tty ?
Re: interesting claims
Hi, El vie., 17 may. 2019 a las 8:22, fungal-net escribió: > > OpenRC: Nice, > init >|_ zsh > when I exited the shell there was nothing but a dead cursor on my screen May I ask what was this setup like? You made a different entry for sysvinit, presumably with the customary getty processes configured in /etc/inittab 'respawn' entries, judging by your results, so how was the OpenRC case different? > sysV: init and 6 ttys with shell ... nothing can kill it that I know off. Thanks, G.
Re: interesting claims
On Wed, 15 May 2019 13:22:48 -0400 Steve Litt wrote: > The preceding's true for you, but not for everyone. Some > people, like myself, are perfectly happy with a 95% reliable system. I > reboot once every 2 to 4 weeks to get rid of accumulated state, or as > a troubleshooting diagnostic test. I don't think I'm alone. Some > people need 100% reliable, some don't. That is a strange point of view: there might be people who doesn't need computers at all. So we shouldn't program anything? So if there are people outside who needs a higher quality and Laurant wants to target them, then he needs to deliver that and it makes sense to argument with that requirement. Best Regards Oli -- Automatic-Server AG • Oliver Schad Geschäftsführer Turnerstrasse 2 9000 St. Gallen | Schweiz www.automatic-server.com | oliver.sc...@automatic-server.com Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47 pgpg5pz6vlCk6.pgp Description: OpenPGP digital signature
Re: interesting claims
On Wed, 01 May 2019 18:13:53 + "Laurent Bercot" wrote: > >So Laurent's words from http://skarnet.org/software/s6/ were just > >part of a very minor family quarrel, not a big deal, and nothing to > >get worked up over. > > This very minor family quarrel is the whole difference between > having and not having a 100% reliable system, which is the whole > point of supervision. The preceding's true for you, but not for everyone. Some people, like myself, are perfectly happy with a 95% reliable system. I reboot once every 2 to 4 weeks to get rid of accumulated state, or as a troubleshooting diagnostic test. I don't think I'm alone. Some people need 100% reliable, some don't. My liking of supervision is not 100% reliability, but instead 95% reliability that is also simple, understandable, and lets me write daemons that don't have to background themselves. I don't think I'm alone. > Yes, obviously sinit and ewontfix init are greatly superior to > systemd, sysvinit or what have you. Which is why I call it a family quarrel. Some in our family have a strong viewpoint on whether PID1 supervises at least one process, and some don't. But outside our family, most are happy with systemd, which of course makes most of us retch. > That is a low bar to clear. And > the day we're happy with low bars is the day we start getting > complacent and writing mediocre software. I'd call it a not-highest bar, not a low bar. Systemd is a low bar. > > Also, you are misrepresenting my position - this is not the first > time, and it's not the first time I'm asking you to do better. > I've never said that the supervision had to be done by pid 1, actually > I insist on the exact opposite: the supervisor *does not* have to > be pid 1. What I am saying, however, is that pid 1 must supervise > *at least one process*, which is a very different thing. I'm sorry. Either I didn't know the preceding, or I forgot it. And supervising one process in PID1 makes a lot more sense than packing an entire supervisor in PID1. > s6-svscan is not a supervisor. It can supervise s6-supervise > processes, yes - that's a part of being suitable as pid 1 - but it's > not the same as being able to supervise any daemon, which is much > harder because "any daemon" is not a known quantity. I understand now. > Supervising a process you control is simple; supervising a process > you don't know the behaviour of, which is what the job of a > "supervisor" is, is more complex. I understand now. Thanks, SteveT
Re: interesting claims
So Laurent's words from http://skarnet.org/software/s6/ were just part of a very minor family quarrel, not a big deal, and nothing to get worked up over. This very minor family quarrel is the whole difference between having and not having a 100% reliable system, which is the whole point of supervision. Yes, obviously sinit and ewontfix init are greatly superior to systemd, sysvinit or what have you. That is a low bar to clear. And the day we're happy with low bars is the day we start getting complacent and writing mediocre software. Also, you are misrepresenting my position - this is not the first time, and it's not the first time I'm asking you to do better. I've never said that the supervision had to be done by pid 1, actually I insist on the exact opposite: the supervisor *does not* have to be pid 1. What I am saying, however, is that pid 1 must supervise *at least one process*, which is a very different thing. s6-svscan is not a supervisor. It can supervise s6-supervise processes, yes - that's a part of being suitable as pid 1 - but it's not the same as being able to supervise any daemon, which is much harder because "any daemon" is not a known quantity. Supervising a process you control is simple; supervising a process you don't know the behaviour of, which is what the job of a "supervisor" is, is more complex. In future presentations, I will make sure to pinpoint the difference. Yes, that is a detail, but this detail is what allows us to make pid 1 both simple (not having the whole supervision logic in pid 1) and correct (covering the case where all processes die). -- Laurent
Re: interesting claims
Jeff: where can i learn how a "correct" init has to operate ? See https://unix.stackexchange.com/a/197472/5132 for starters.
Re: interesting claims
"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 ? For instance: https://archive.fosdem.org/2017/schedule/event/s6_supervision/ https://www.youtube.com/watch?v=I7qE43KK5bY=7591 https://www.reddit.com/r/linux/comments/2dx7k3/s6_skarnetorg_small_secure_supervision_software/cjxc1hj/?context=3 Or, as Guillermo mentioned, several posts in the ML archive. init is a subject that little study has been put into (though it is also the subject of a whole lot of talk, which says something about whether people would rather talk or study). But I think you'll find that things are different around here. or is it true since s6-svscan already provides such respawn capabilities ? ;-) Do not mistake causes for consequences. Things are not correct because s6 does them; s6 does things because they are correct. there is actually NO need for a "correct" working init implementation to provide respawn capabilities at all IMO. 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. However, you sound interested in process supervision, which is part of the more general idea that a machine should be made as reliable as possible *at all times* and *under any circumstances*; if you subscribe to that idea, then you will understand why init must supervise at least 1 process. so this looks like a rather artificial and constructed argument for the necessity of respawn functionality in an init implementation IMO. Maybe you've never bricked a device because init didn't respawn anything. I have. The "rather artificial and constructed argument" happened to me in real life, and it was a significant inconvenience. -- Laurent
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:
