Secondly, once that actually works, oom-protecting - or not - more stuff would be desirable.
Dropbear could run out of xinetd for sure… rsync already runs out of xinetd, netperf does also but some tests fail on the svn version.
Perhaps git-daemon…
Definately some sensors…
It would be great of lighttpd could run out of xinetd - or some web server - as you only need the web server running rarely… iperf -s doesn’t work out of xinetd either….
nearly every daemon could run out of something like xinetd (I’m not sold
on xinetd, or init, but
leaving processes around, unmonitored, is a sure recipe for eventual
failure) Monit maybe. systemd and launchd are way too big and
overdesigned for this task.
that said I have half a patch for xinetd to better control the oom-killer, but for some reason it couldn’t set child processes to anything other than 0 or 1000. I liked very much that it could set itself to 1000, however, and I thought about putting it in regardless of the problems.
if anybody wants to play with it, I’ll upload it here.
Part 2 is to get more stuff into inetd.
But no matter what I try, it also makes all the child processes -1000.
Ripped patch out of build.