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.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState