3 ms·
Well, I want PID 1 to make exactly one userland binary call and then start reaping orphans. I want that PID 2, the RC system, to read some configuration file(s)
by bandrami 10y ago
Well, I want PID 1 to make exactly one userland binary call and then start reaping orphans. I want that PID 2, the RC system, to read some configuration file(s) and, yeah, fork and exec a bunch of userland binaries. It's kind of the whole point, right?
- bonzini 10y agoWhat's the advantage of such an architecture?
- bandrami 10y agoThe advantage is that the kernel panics if PID 1 ever crashes, so I want PID 1 never to crash or even be able to crash. It also means I want the binary to have as little of an attack surface as possible, and particularly I don't want it listening to dbus or having links to a QR generation library. This is a solved problem with multiple good solutions [1] [2] [3], so I can easily avoid those issues by not using systemd. [1] http://www.gnu.org.ua/software/pies/ http://www.gnu.org.ua/software/pies/ [2] http://universe2.us/epoch.html http://universe2.us/epoch.html [3] http://core.suckless.org/sinit http://core.suckless.org/sinit
- bonzini 10y agoSo add a signal handler that just enters an endless loop. That's what systemd does, so as not to panic the kernel on a crash. By the way, systemd doesn't listen to dbus (it uses the dbus protocol for IPC) and does not link to a QR generation library (journalctl does, which is your usual unprivileged program).