== Ubuntu's attention to detail in _init.d_ scripts # /etc/init.d/exim4 stop Stopping MTA: exim4. # pidof exim4 3559 # grep PIDFILE /etc/init.d/exim4 | sed 1q PIDFILE="/var/run/exim4/exim.pid" # ls -ld /var/run/exim4 ls: /var/run/exim4: No such file or directory # mount | fgrep /var/run varrun on /var/run type tmpfs (rw) Well, that would explain it. It turns out that the official Ubuntu exim4 package (which is in their core repository, not one of the less supported expanded ones) creates _/var/run/exim4_ in its post-install script. This probably works well on Debian, where I suspect that _/var/run_ is part of a persistent filesystem, but works rather less well on Ubuntu (and fails mysteriously; '_exim4 stop_' and '_exim4 restart_' work fine after you install exim4 up until you reboot the machine). And Ubuntu clearly didn't make a systematic sweep through all packages looking for things that needed _/var/run_ subdirectories when they decided to make _/var/run_ a volatile filesystem. (They weren't completely ignorant of the whole issue, since _/etc/init.d/klogd_ carefully creates its _/var/run_ directory every time.) In general, I have not been pleased with Ubuntu's entire _/etc/init.d_ setup. Coming from a Red Hat/Fedora Core environment, I keep finding things missing, like syslogging of the results or a consistent format for startup scripts and information about them. (Ubuntu has the start of this in some init scripts, with the 'BEGIN INIT INFO' section, but only about half of the init scripts on my test machine seem to use it.) (I suspect that this anarchism and lack of features is a sign of Ubuntu's status as a relatively thin veneer over Debian. The Debian policy guide [[section on _init.d_ scripts http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit]] is pretty basic, which is a recipe for widely divergent init scripts.)