Dear Marc,

     This makes sense if we consider the very old way a Linux system was 
run:
         boot; then mount filesystems, them start syslog; then 
initialize network; then start nfs and ssh ...
     then stop daemons in the reverse order, unmount filesystems and 
shutdown.

     A more modern way of starting daemons is to have fine-grained 
dependencies. Instead of waiting until syslogd is started, why not wait 
until the socket /var/log is created, or create it even before starting 
syslogd.

     And furthermore, is it really necessary to wait for anything before 
starting the daemons; why wait until the network is configured to start 
ssh and nfs?

     Things are not going the linear way anymore. The network cable, as 
an example, can be disconnected and reconnected, and the network 
interface de-configured and re-configured, and the ssh daemon will 
survive, and NFS as well. Even you can reboot an nfs server and clients 
having their rootfs nfs-mounted come back to life seemlessly.

     Daemons should be prepared to wait until the needed ressource is 
available; they should even be prepared to see the ressource they need 
disapear and to wait until it shows up again.

     You make a very good point - often forgotten , including by me -  
about daemon's current directory. But about orphanning the daemons, I 
disagree. I used to do like you for my private daemons, and to manage 
pid-files, but it was because I repeated the same scheme by pure 
lazyness. I am decided to now use a supervisor.

     Didier