20 ms·
So you want pid1 constantly calling out to userland binaries to do basic filesystem manipulation tasks?
by xena 10y ago
So you want pid1 constantly calling out to userland binaries to do basic filesystem manipulation tasks?
- bandrami 10y agoWell, 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).