SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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)
Click here to see the post LQ members have rated as the most helpful post in this thread.
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.
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