Making Sense of startup
Many modern operating systems are happy to display a "please wait" splash screen while booting--not so with Linux. Unlike other operating systems, Linux is incredibly chatty while it boots, and I'm often asked by new users to explain all the messages that appear during startup. There's a raft of what appears to be random messages, followed by a collection of more ordered messages that appear as each of the operating system services start. If the install/boot went well, these ordered messages are accompanied by a brightly coloured (usually green) OK or DONE. If something goes wrong, the messages usually display FAILED in red. Unfortunately, both the random and the ordered messages disappear off the screen quickly, usually well before a new user has had a chance to read them.
It is possible to view the initial, random messages using the dmesg command. A quick read of the dmesg manpage states that dmesg is a utility that can "print or control the kernel ring buffer". Among other things, the kernel ring buffer is the place where boot messages are logged. The following command line displays the ring buffer's current contents; notice the piping to less, which displays the messages one screen at a time:
dmesg | less
By piping the dmesg command through grep, it is possible to extract some specific data. For instance, use this command line to learn about your system's USB setup (note the -i argument to grep, which instructs the utility to ignore case, allowing USB as well as usb to match):
dmesg | grep -i 'usb'
Replace the filter value to extract other useful information. For example, replacing usb with hd provides information on the hard-disks detected at boot-time. Equally, cpu extracts data on your computer's chip, whereas net extracts data on your network setup. Using scsi displays data on any SCSI devices, including CD-ROMs.
As part of the Linux boot, the init process executes and the operating system enters one of a fixed number of runlevels. The list of runlevels are described at the start of the following configuration file, which is used by the init process:
Typically, as a result of a fresh install, your computer is configured to boot into one of two runlevels, either runlevel 3 or runlevel 5. The former starts Linux in full multiuser mode, presenting a text-based login screen after a successful boot. The latter also starts Linux in full multiuser mode, but a graphical, X11-based login screen is presented. Which option you choose is a personal preference, and your Linux installation program typically lets you choose either a text-based or graphical login to use as the default. The /etc/inittab file indicates on the id line which runlevel currently is the default on your system. As I tend to boot to a text-based login on all my systems, my id line within /etc/inittab looks like this:
If I change the 3 to a 5 and reboot, the graphical, X11-based login screen appears. In order to edit the /etc/inittab file, superuser privilege is required, so remember to log in as root when editing this file.
The purpose of the various runlevels is to arrange for a specific set of services to be started or stopped under certain circumstances. Runlevels exist to reboot and halt the system, in addition to starting services at boot-time. It is these services that relate to the more ordered OK messages displayed at boot-time, as mentioned at the start of this article.
A series of system service scripts exist in the /etc/init.d/ directory. Another collection of subdirectories located under the /etc/rc.d/ directory corresponds to each of the runlevels. Symbolic links within these subdirectories point to the service scripts. By adding/removing symbolic links from the appropriate subdirectory, it is possible to adjust which service scripts execute when Linux enters a specified runlevel. However, doing so manually is often too much work. In my view, it is much better to rely on a semi-automated tool, such as chkconfig, to do the bulk of this work for you.
The chkconfig utility allows you to update and query the runlevel information for your system services. Rather than fiddling with symbolic links, directory entries and service scripts, chkconfig does the fiddling for you. Scripts are added or removed from the appropriate rc subdirectory as needs be, allowing startup services to be controlled more easily.
chkconfig typically resides in the /sbin/ directory, so be sure to issue the following commands as root. To review the entire list of startup services, sorted alphabetically, use this command line:
chkconfig --list | sort | less
A listing of the services appears, each accompanied by an indication as to whether the service is enabled (on) when a particular runlevel is activated or disabled (off). As always, the output is piped to less to stop it scrolling off the screen. It often is useful to determine which of these services are enabled. To do this, filter the output through grep, as follows:
chkconfig --list | sort | grep ':on' | less
In addition to listing the current state of each of the startup services, ckconfig also can switch services on and off, with any changes taking effect after the next boot. This means that if a service is enabled and then is switched off with chkconfig, it remains running until the system reboots. To switch the service off immediately, simply execute the service script (as root), passing the word stop as a command-line parameter. For example, to arrange for the ISDN service to no longer start at boot-time, issue this command:
chkconfig isdn off
his line ensures that the ISDN service is disabled at the next reboot. To turn off the ISDN service without rebooting, use this command:
If you haven't switched off the ISDN service with chkconfig, it will restart as part of the next reboot, even though you stopped it by executing the service script. So, to immediately and permanently stop the ISDN service, issue the above commands together:
chkconfig isdn off && /etc/init.d/isdn stop
To control which startup services are enabled at boot-time, work through the list of services identified by chkconfig, switching on those you want enabled and switching off those to be disabled. This is easy to do when using chkconfig, assuming you know what each of the startup services do. If you are unsure, two techniques can help you to learn. The first is straightforward: see if a manpage exists for the service in question. For example, to display the manpage associated with the crond service, issue this command line:
Assuming the manpage exists, it should provide plenty of information about what the service does. You then can decide if you want the service to start at boot-time and then use chkconfig to enable or disable the service as need be. If no manpage is available (there isn't for the ISDN service on my Red Hat 9 system), a message similar to this appears:
No manual entry for isdn
To determine what the ISDN service does, the second technique is to take a look at the actual startup script stored in the /etc/init.d/ directory using less. For example:
Although the displayed script may look a little strange, concentrate on the comment lines--they start with #--near the top of the script. There should be a line labeled description to provide a clue as to what the script does. For the ISDN service, the clue couldn't be more clear:
# description: start and stop ISDN services
By working through the set of startup service scripts in an ordered way, it is possible to configure services to suit your requirements. In doing so, you learn what it is Linux is doing during the boot process. Although GUI-based versions of chkconfig exist and often are convenient to use, they assume the administrator is located physically in front of the computer being managed. When accessing a system for essential maintenance over a slow dial-up or remote network connection, the command line based chkconfig is the only way to go.
For more information on chkconfig, be sure to read its manpage. To learn more about the boot process, start with the init manpage.
Paul Barry (firstname.lastname@example.org) lectures at the Institute of Technology, Carlow, in Ireland. He is the author of Programming the Network with Perl (Wiley 2002). His new book, co-authored with Dr. Michael Moorhouse (of Erasmus MC, The Netherlands), is titled Bioinformatics, Biocomputing and Perl (Wiley 2004).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide