Cool story! I can only imagine how good the person solving the riddle felt when the penny finally dropped! :) Two somewhat topical observations in a similar ve

Cool story! I can only imagine how good the person solving the riddle felt when the penny finally dropped! :) Two somewhat topical observations in a similar vein: Back in a sysvinit world, many (Debian) users would run init-scripts directly via `/etc/init.d/someservice someaction`, instead of using `/usr/sbin/service someservice someaction`. This could have very unpleasant side effects at times, because `service` is/was actively trying to clean and sanitize the resulting child processes' environment, while most init scripts themselves usually did not. The second thing that the article made me think of is not directly related to most "admin wants the system to start a service"-scenarios, but COULD also happen in such a situation: On Linux, when a process tries to fork, the kernel requires certain guarantees in terms of usable memory for the process' copy, due to copy-on-write semantics for allocated pages. If these cannot be matched, forking might fail with ENOMEM. In my experience, this is much more likely to happen when the process trying to fork has a lot of allocated memory accounted for. Therefore, it makes perfect sense to have a "lightweight" kind of fork-and-exec-server around in the system that can be contacted via an IPC mechanism, and made to start daemon processes that are probably not meant to inherit anything from the caller's environment (like file descriptors, niceness, environment variables) in the first place.