Reading time: 2 minutes
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.
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.
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:
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.
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
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 …