rc.local runs after all the runlevel start scripts - so it's not really a good place to configure things those scripts are going to need. I've done some poking around in rc.s... [by Moray]
on 06/29/2012 – Made popular on 06/29/2012
I was trying to debug my linux boot process. If I set default runlevel to 2 or 3 my system hangs without giving me prompt. So I was able to get to runlevel 1 via kernel parameter. and ran all scripts in rc2.d via service ***** start/stop commands and it was fine. But if I do a telinit to runlevel 2 or 3. I cant see my shell prompt. So what is the diff between to approaches ?
This tutorial will show you how to automatically execute commands at the system start-up using the standard init.d directory and the default runlevel. These scripts are called init scripts or start-up scripts, they are used to start and stop services and they will be executed with root privileges.
I'm getting really frustrated trying to get some init scripts to work.
I've read up on LSB and the ubuntu man pages, and AFAICT, to get my init scripts to run at a specific point in the startup order, I should have to do no more than define the Required-Start, and X-Start-Before LSB headers in my script.
However, on the (14.04b1) installation I'm trying to get this working on, all update-rc.d do
I need to re-order init scripts, particularly so that some of my own will run before certain others. What documentation should I be looking at for thorough information on how that is done (aside from the effects of the changes).
This is in a cloud environment using the cloud-images tree, with cloud-init in the mix.
I have read the Linux FHS, but still feel a little confuse. If I have some utility shell scripts, shall I put them in /usr/bin or /usr/local/bin or ~/bin?
The FHS says the most user commands goes to /usr/bin, but it also says that administrater should install unpackaged app or host specific stuff in /usr/local, does that means the /usr/local/bin is a better place for my own scripts?