Re: what init systems do you use ?
El jue., 2 may. 2019 a las 21:53, Jeff escribió:
>
> what init systems do this list's subscribers use ?
I have a Gentoo setup with no initramfs and one of the stable desktop
profiles (in the 'eselect profile' sense, which means GNU libc with
dynamic linking), that allows me to boot with an assortment of init
systems using the GRUB2 menu:
* sysvinit + OpenRC, using agetty from util-linux, to get a fully
functional system with one of the distribution's officially supported
configurations.
* runit + OpenRC, again using agetty from util-linux, to get a
somewhat restricted system for experimentation. Gentoo packages runit,
and OpenRC gets used because it is invoked by the supplied
/etc/runit/{1,3} files. Notable drawback: OpenRC's service scripts in
the sysinit and boot runlevels may launch unsupervised daemons that
runit doesn't know about.
* s6 + s6-rc, with version 0.4.x.x s6-linux-init-style scripts, again
using agetty from util-linux, to get an even more restricted system
for experimentation. OpenRC is inactive in this case, since s6-rc is
the service manager.
* nosh, with agetty replaced by a combination of the package's tool,
to get the same restricted system as for s6 + s6-rc. OpenRC is also
inactive in this case, since nosh contains a service manager (in the
skarnet.org documentation sense).
The "restricted system" scenarios would be less restricted, of course,
if I wrote, o grabbed and adapted from somewhere else, enough service
definitions for the selected init system, to match the sysvinit +
OpenRC configuration, but that means work of course.
G.
Re: emergency IPC with SysV message queues
Please stop breaking threads. This makes conversations needlessly difficult to follow, and clutters up mailboxes. Your mailer certainly has a "Reply" or a "Reply to group" feature, that does not break threads; please use it. that is wrong. just read the msg queue when a signal arrives (say SIGIO for example). catch that signal via selfpiping and there you are, no need to use threads. That is obviously not going to work. Operations such as msgsnd() and msgrcv() are synchronous and cannot be mixed with asynchronous event loops. There is no way to be asynchronously notified of the readability or writability of a message queue, which would be essential for working with poll() and selfpipes for signals. If you are suggesting a synchronous architecture around message queues where the execution flow can be disrupted by signal handlers, that is theoretically possible, but leads to incredibly ugly code that is exceptionally difficult to write and maintain, to the point where I would absolutely choose to use threads over this. Interruption-driven code was common in the 1990s, was a complete nightmare, and thankfully essentially disappeared when Linux implemented a half-working threading implementation. I would not trust myself to write correct interruption-driven code, let alone make it readable by other programmers. You should not trust yourself either. Every modern Unix can mount a RAM filesystem nowadays, that is a poor excuse, you wanted to portable, right ? Yes. Every modern Unix system has a way to create and mount a RAM filesystem. The APIs themselves are not portable, and that is why s6 doesn't do it itself, but the concept totally is. If I had more experience with the BSD APIs, I could easily port s6-linux-init to the BSDs. I hope someone more BSD-savvy than me will do so. Using non-portable *functionality*, on the other hand, is an entirely different game. Abstract sockets only exist on Linux, and porting code that uses abstract sockets to another platform, without using non-abstract Unix domain sockets, is much more difficult than porting code that mounts a tmpfs. use the console device for your early logs, that requires console access though ... I said *logs*, as in, data that can be accessed later and reused, and maybe stored into a safe place. Scrolling text on a console is no substitute for logs. that is just your opinion since your solution works that way. That is my opinion backed by 20 years of experience working with Unix systems and 8 years with init systems, and evidence I've been patiently laying since you started making various claims in the mailing-list. You are obviously free to disagree with my opinion, but I wish your arguments came backed with as much evidence as mine. you can tell a reliable init by the way it does ipc. many inits do not get that right and rely on ipc mechanisms that require rw fs access. if mounting the corresponding fs rw fails they are pretty hosed since their ipc does not work anymore and their authors were too clueless to just react to signals in case of emergency and abused signal numbers to reread their config or other needless BS. i top my claims even more: you can tell a reliable init by not even using malloc directly nor indirectly (hello opendir(3) !!! ;-). :PP Every piece of software is a compromise between theoretical minimalism / elegance and other requirements. Even minimalism and elegance are sometimes subjective: my position is that using s6-svscan as process 1 is more elegant than having a separate "minimal" process 1 that still needs to perform some kind of supervision, because writing the separate process 1 would lead to some functionality duplication and also add more code. Your opinion is obviously different; instead of taking cheap shots, show me the code, and then, maybe, we can compare merits. -- Laurent
emergency IPC with SysV message queues
10.05.2019, 20:03, "Laurent Bercot" : > Have you tried working with SysV message queues before recommending > them ? yes, i had the code in an init once, but i never completed that init. but dealing with SysV msg queues was not such a big deal from the code side. i used it merely as an additional emergency ipc method when other ipc methods become impossible. though actually signals were sufficient in case of emergency. > Because my recommendation would be the exact opposite. Don't > ever use SysV message queues if you can avoid it. The API is very > clumsy, and does not mix with event loops, so it constrains your > programming model immensely - you're practically forced to use threads. > And that's a can of worms you certainly don't want to open in pid 1. that is wrong. just read the msg queue when a signal arrives (say SIGIO for example). catch that signal via selfpiping and there you are, no need to use threads. we were talking about process #1 anyway, so some msg queue restrictions do not apply here (like finding the ipc id), if you need to send replies back to clients set up a second queue for the replies (with ipc id 2, we are process #1 and free to grab ANY possible ipc id). if those clients wait for their results and block you could also signal them after writing the reply to the second queue (that means clients send their pid along with their requests, usually the message type field is (ab ?)used to pass that information). > Abstract sockets are cool - the only issue is that they're not > portable, which would limit your init system to Linux only. well, we are talking about Linux here since that is where that obscene systemd monstrosity rampages for quite a while now. > If you're going for a minimal init, it's a shame not to make it > portable. in my case it will be portable and will work solely signal driven. but i do not see to much need for other unices to change their init systems, especially not for BSDs. of course BSD init could be improved upon but it just works and it is rather easy to understand how. they did not follow the SysV runlevel BS and speeding their inits up will mostly mean to speed up /etc/rc and friends. it also has respawn capabilities via /etc/ttys to (re)start a supervisor from there. though i agree it is quite big for not doing too much ... i hope the FreeBSD (i do not think the other BSDs even consider such a step) team will not follow the BS introduced elsewhere (OpenBSD will probably not), a danger for FreeBSD was some of their users' demand to port that launchd joke over from macOS or come up with something even worse (more in the direction of systemd). > Really, the argument for an ipc mechanism that does not require a > rw fs is a weak one. not at all. > Every modern Unix can mount a RAM filesystem nowadays, that is a poor excuse, you wanted to portable, right ? > and it is basically essential to do so if you want early logs. use the console device for your early logs, that requires console access though ... > Having no logs at all until you can mount a rw fs is a big > no-no, and being unable to log what your init system does *at all*, > unless you're willing to store everything in RAM until a rw fs > comes up, is worse. An early tmpfs technically stores things in RAM > too, but is much, *much* cleaner, and doesn't need ad-hoc code or > weird convolutions to make it work. > Just use an early tmpfs and use whatever IPC you want that uses a > rendez-vous point in that tmpfs to communicate with process 1. > But just say no to message queues. that is just your opinion since your solution works that way. other solutions are of course possible, eg using msg queues just as a backup ipc method since we can exploit being process #1 here. in the case of Linux i do not see any reason not to use abstract unix sockets as preferred ipc method in process #1 (except the kernel does not support sockets which is rare these days, right ? on BSD AFAIK the kernel also supports sockets since socketpairs were said to be used there to implement pipes.) for BSD use normal unix sockets (this is save to do even on OpenBSD since we have emergency ipc via signals and SysV msg queues), on Solaris SysV streams (and possibly doors) might be used as we also have said backup mechanism in reserve. but to be honest: a simple reliable init implementation should be solely signal driven. i was just thinking about more complex integrated inits that have higher ipc demands (dunno what systemd does :-). you can tell a reliable init by the way it does ipc. many inits do not get that right and rely on ipc mechanisms that require rw fs access. if mounting the corresponding fs rw fails they are pretty hosed since their ipc does not work anymore and their authors were too clueless to just react to signals in case of emergency and abused signal numbers to reread their config or other needless BS. i top my claims even more: you can tell a reliable init by not even using malloc directly nor
