It is my understanding of the rc scripts (which in my opinion are awesome due to their amazing flexibility) that rc.S is called at every start-up, and rc.M is called when going multiuser. I setup my box to boot straight to X, so I guess rc.S is called then rc.M after that.

Recently (it might have been an update that did it, I'm not sure though - I use current btw), I've been able to chase down the cause of an annoying halt while going multiuser, specifically when starting the udev daemon. My guess is that because rc.S has already started it, it hangs around for a minute or so, then gives up, blurts out an error message stating udev is already running (which I only got after some fiddling with rc.udev) and boot carries on as normal.

My question is, simply, should this have happened? In rc.udev there is a section which deals with being called when udev is already running, but obviously it did't work. I have commented out the section starting up udev in rc.M and all seems fine now. Why the duplication between the files?

Or (as I am a noob) am I just getting completely the wrong end of the stick here? I've learnt a lot by working this through though. (i think :s)

It's not the same command. When udev is first run it process cold-plug events -for things which were already plugged in at boot-time. When it runs later, it is so that it can process new kernel events. Both are necessary -look closely at the detail of the two commands.

2 members found this post helpful.

Thanks for the reply gnashley.

I booted with the second udev call commented out but the pause still occurred, so I looked through the output of dmesg and it seems there are some read errors on my hard disk, and the kernel was doing something with the disk just as udev was being restarted.

My own fault here for reading the signals wrong I guess.

I have thus reinstated the multiuser udev call and apologised to it

"and apologised to it": LOL