Damned axe ...

Damned axe … is it really that hard to believe that an automatic system in Debian makes a dumb decision based on dumb assumptions (classic BIBO - bullshit in , bullshit out) ? It has nothing to do with a butchered up distribution by a hosting provider or an error between the keyboard and the chair. I would consider it a bug if it would deliver a differen result given the input to the system and the ruleset codified in the system.

Per default an init.d script is inserted by the insserv in the init.d scripts in debian. If you have ever wondered about the comments section at the beginning of the init.d scripts in debian … they are the input for insserv to build up the dependency graph.

root@narf /etc/init.d # head ssh
#! /bin/sh

### BEGIN INIT INFO
# Provides:             sshd
# Required-Start:       $remote_fs $syslog
# Required-Stop:        $remote_fs $syslog
# Default-Start:        2 3 4 5
# Default-Stop:
# Short-Description:    OpenBSD Secure Shell server
### END INIT INFO

This information is used to put the init.d script at the right place of the sequence of startup.

There is a number of scripts just dependent on the existence of the local filesystem. This ones are run with the sequence number 01 thus first.

root@narf /etc/rc2.d # ls -l S01*
lrwxrwxrwx 1 root root 20 Oct 25 10:46 S01fancontrol -> ../init.d/fancontrol
lrwxrwxrwx 1 root root 19 Oct 25 10:40 S01mailgraph -> ../init.d/mailgraph
lrwxrwxrwx 1 root root 17 Oct 25 08:58 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 19 Oct 25 10:45 S01saslauthd -> ../init.d/saslauthd
lrwxrwxrwx 1 root root 14 Oct 25 10:42 S01sudo -> ../init.d/sudo

One of the services started first is syslog, and as you may have recognized in the head of the ssh init.d script, ssh depends on it. So it gets a higher sequence number and thus it's started later:

root@narf /etc/rc2.d # ls -l *ssh
lrwxrwxrwx 1 root root 13 Oct 25 10:44 S04ssh -> ../init.d/ssh/pre>

But wait, what has happened with 02 and 03? They are used by a single service each:

root@narf /etc/rc2.d # ls -l S02*
lrwxrwxrwx 1 root root 17 Oct 25 10:41 S02apache2 -> ../init.d/apache2
root@narf /etc/rc2.d # ls -l S03*
lrwxrwxrwx 1 root root 17 Oct 25 10:44 S03openvpn -> ../init.d/openvpn

Why do they have this special treatment. It's pretty simple. Both services are flagged as being interactive, as they could ask for some user interaction.

root@narf /etc/rc2.d # grep -i "INTERACTIVE" *
S02apache2:# X-Interactive:     true
S03openvpn:# X-Interactive:     true

In this cases both might probably ask for a password for the key. They have to start early to be sure that nothing can gets and block the tty in order to enable both scripts to show the password dialog. Keep in mind that we are in a state where no getty is running. However they can't earlier, as both rely on syslog. Essentially they are started as soon as possible and before other scripts with the same dependencies. And thats basically a part af the problem.

And this essentially leads to the situation, that apache2 was started before ssh.

Another reader hinted me to the fact that lightttpd starts after ssh. At first this is just of cursory interest at a situation where the webserver in question is apache. At second the dependencies are different. At first the init.d script for lighty has no # X-Interactive: hint and at second there is a condidtional (obey it, when it's installed and configured to run, otherwise ignore it) dependency to fam (file alteration monitor) that the ssh script don't have. And fam relies on portmap. Thus the dependencies are a little bit longer thus it's no wonder that you see lighty starting after ssh.

I won't comment what i'm thinking about such a … a… a… solution ...