Michael Biebl <bi...@debian.org> writes: > Why is a system service that is started by inetd or D-Bus not a daemon? > Remember the times when exim4 or samba could still be started via inetd > (although those no longer support inetd mode afaik).
Why would you store your PID somewhere if you're started from inetd (that's the main thing daemons use it for)? There's nothing to manage; when you're running in inetd mode, you process one connection and exit. There's no purpose served by storing the PID anywhere (and indeed since multiple copies can be running at the same time, it's not clear how you would even do such a thing). > There are still daemons though (like proftpd comes to mind), which ship a > subdirectory in /var/run and support inetd. What does it use the directory for? > PolicyKit stores credentials in /var/run/PolicyKit which are of > temporary nature and are automatically cleaned up on boot. Oh, okay, so you're similar to sudo where you're taking advantage of the fact that /var/run is cleaned on boot but isn't world-writable. sudo appears to create its directory dynamically if it doesn't already exist. I assume the reason why you can't take that approach is that PolicyKit doesn't run as root and hence can't create directories in /var/run? I believe the original motivation for tmpfs /var/run in Solaris was that it was pointless to maintain scripts that try to clean /var/run (or /tmp or any other defined-transient directory) on boot, which can be dangerous and tricky if you don't write them carefully, when you can just put them in tmpfs and have the cleaning happen automatically without doing any work. It simplifies the boot process and eliminates a whole class of potential directory traversal races that you otherwise have to think about. Potential additional boot speed from writing all the startup PID files to a tmpfs file system (and benefits for flash drives as the only system storage and similar special configurations) are just a bonus. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org