most init systems do have a legitimate use case for touching a file.
Can you name such a legitimate use case then? All I can think of is the need to write a pid file, and pid files are a kludge that real service supervisors gladly do away with.
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?
The 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.
So 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).
Can you name such a legitimate use case then? All I can think of is the need to write a pid file, and pid files are a kludge that real service supervisors gladly do away with.