Making Sense of startup

Some tips for figuring out what all the startup messages flying by your screen actually mean.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

seeing the non-random messages

Chris Bradshaw's picture

I'd like to point out that you can see the non-random boot messages (with a green OK or a red Failed) by running
/etc/init.d/xxxx start
where xxxx is the name of the service that failed. AFAIK these messages are not stored in any log file, so this is the best way to see them again...

Too nice :)

EmuGuru's picture

Thanks for this informative little article, it helped a lot!

Very clear and usefull. Thank

Anonymous's picture

Very clear and usefull. Thanks

Re: Making Sense of startup

Anonymous's picture

If I change the 3 to a 5 and reboot, ...

A Linux box rarely needs to be rebooted for a change to take effect. Changes to some configuration files take effect as soon as the updated config file is saved by your editor, e.g., /etc/resolv.conf. For others you must inform the relevant service (daemon) of the change, usually by running the service's startup script with a reload or restart option (see service command on RedHat, maybe others too. Basically it supplies the path to the startup script for you.), or send a signal (HUP is common) to the daemon with the kill command. Some services have their own program for this purpose, e.g., ndc or rndc in BIND. Find out the difference between restart and reload options for each service you use. Some times they are identical, but not always. If you do reload on named the cache is preserved. If you do restart the cache is lost.

In the case cited above, changing the default run level in /etc/inittab, you tell init that it's config file has changed by running: init q or telinit q. If you have made a lot of changes it may be desirable to change to run level 1 (single user mode) and back to the desired run level, usually 3 or 5. Just do: init 1 wait for services to stop, then do: init 3 or init 5.

When must you reboot? After upgrading the kernel, after a kernel panic or hang, when doing anything that requires the power to be removed, BIOS setting changes, or testing changes to the startup or shutdown process to verify that they work correctly. There may be some other obscure situations requiring a reboot but I have not exprienced any others in 10+ years of using Linux.

If you can keep the power on, startup rarely happens. I have a Linux NFS server that has been up for 414 days as of today. Others have had them up even longer.

The "make a change and reboot" mindset comes from outside of the Unix/Linux world.

Re: Making Sense of startup

barryp's picture

Thanks for the comment. I agree with what you say. However, the article was aimed at non-Linux users and newbies. The vast majorty of them come from "the other side" and I went with the familiar rather than go into the whole "there's no need to reboot" explanation. I was trying to keep things as simple as possible for an article of this type. Your point is well made and taken. Thanks again. --Paul.

Re: Making Sense of startup

Anonymous's picture

In my experience, chkconfig is a tool on Redhat-based distros only; I have not encountered it on Slackware or Debian-based distros. It would have been nice of the author (or editors) to note this during this otherwise useful article.

For those interested, on Debian-based machines, the script update-rc.d performs much (but not all) of the functionality of chkconfig.

Re: Making Sense of startup

Anonymous's picture

You can use :
SUSE 7.x : rc-update.d (--? for help)
Gentoo : rc-update (--? for help)



Re: Making Sense of startup

barryp's picture

Thanks for that comment. chkconfig is available on RedHat (and it close cousins) as well as SuSe. Thanks for the pointer to the Debian tool. -- Paul.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot