Making Sense of startup

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

Comments

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)

regards,

Fernando

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.

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions