RHEL Runlevels

You can change runlevel specified in init at grub menu during boot. This is useful if the system has default runlevel 5 and X server hangs. Switch to 3 allow to boot the server and make necessary changes.

Red Hat defined the following Runlevels:

• 0 - Halt, init 0 is similar to shutdown -h now
• 1 - Single user, runs just /etc/rc.d/rc.sysinit. Does not run /etc/rc.d/rc
• 2 - Multiuser, with networking (sshd, syslogd, Sendmail, no firewall), but without NFS (The same as 3, if you don't have networking)
• 3 - Full multi-user (firewall, rpc, nfs, ntpd). Console logins only (no X11). 
• 4 - Not used/undefined
• 5 - Full multi-user, with  additional network services ( httpd, vsftpd), X11 and display manager as well as console logins
• 6 - Reboot

The message "Uncompressing Linux..." signals that the kernel taking control of your hardware. It checks and sets your console -- more precisely: the BIOS registers of graphics cards and output format -- to read BIOS settings and to initialize basic hardware interfaces. Next, your drivers "probe'' existing hardware and initialize it accordingly. After checking the partitions and mounting the root file system, the kernel starts init, which "boots'' Unix by executing so called startup scripts.  

All other processes are considered child processes of init. It is started directly by the kernel and resists signal 9, which normally kills processes.

init is  configured via the /etc/inittab file. That's were all runlevels are defined. It also specifies which services and daemons are available in each of the levels. Depending on the entries in /etc/inittab,  set of scripts are run by init. All startup scripts reside in the directory /etc/init.d but are symbolically linked to an appropriate run level directories (rc0.d-rc5.d and rcS.d).

The entire process of starting the system and shutting it down is maintained by init. From this point of view, the kernel can be considered a "mothership" process whose task it is to support all other processes, which are making Unix API calls. It also can adjust CPU share and hardware access according to requests from other programs.

Each runlevel specify set of daemons that are started in case of startup or shut-down in case of shutting system down. The default runlevel to which system is booted is defined in /etc/inittab in the line initdefault. Usually this is 3 or 5.  Please note that generally servers should run on run level 3. runlevel 5 should be used for maintenance only.

You can also assigning a final runlevel at boot time (e.g. , at the boot prompt). The kernel passes any parameters it does not need directly to init.

To change Runlevels while the system is running, enter init and the corresponding number as an argument. Only root is allowed to do this.

• init 1 (or shutdown now) causes the system to change to single user mode, which is used for system maintenance and administration. After finishing his work, the administrator can switch back to the normal runlevel by entering init 3, which starts all the essential programs and allows regular users to log in and to work with the system. On the other hand, init 0 (or shutdown -h now) causes the system to halt. init 6 (or shutdown -r now) causes it to shut down with a subsequent reboot.
• You should not use runlevel 2 if your system mounts the /usr partition via NFS. The /usr directory holds important programs essential for the proper functioning of the system. Because the NFS service is not made available by runlevel 2 (local multiuser mode without remote network), the system would be seriously restricted in many aspects.
• Runlevel 5 is the default runlevel in all SuSE Linux standard installations. Users are prompted for login directly under a graphical interface.

For example is you changed configuration of the X Window System working on runlevel 2 or 3 and need to test the results, change the runlevel to 5. Try it first by typing init 5 to see whether the system works as expected. If it does, use YaST to set the default runlevel to 5.

If /etc/inittab is damaged, the system might not boot properly. Therefore, be extremely careful while editing /etc/inittab and always keep a backup of an intact version. To repair damage, try entering init=/bin/sh after the kernel name at the boot prompt to boot directly into a shell. After that, replace /etc/inittab with your backup version using the cp command.

Generally, two things happen when you change runlevels.

For example, the following occurs when changing from runlevel 3 to 5:

When changing into the same runlevel as the current runlevel, init only checks /etc/inittab for changes and starts the appropriate steps (e.g. , for starting a getty on another interface).

NEWS CONTENTS

• 200208 : Runlevel - Wikipedia, the free encyclopedia ( Runlevel - Wikipedia, the free encyclopedia, )
• 200208 : An introduction to services, runlevels, and rc.d scripts by Mark Alexander Bain ( January 11, 2006 , Linux.com )
• 200208 : Linux Setup - F*king Beagle on Suse 10 ( Linux Setup - F*king Beagle on Suse 10, )

Old News ;-)

Runlevel - Wikipedia, the free encyclopedia

[edit] Red Hat Linux[5]

Red Hat as well as most of its derivatives uses runlevels like this:

• 0 - Halt
• 1 - Single user
• 2 - Not used/User definable
• 3 - Full multi-user, console logins only
• 4 - Not used/User definable
• 5 - Full multi-user, with display manager as well as console logins
• 6 - Reboot

Which services are started in which runlevels can be managed with the chkconfig tool, which keeps its configuration settings in a mildly elaborate arrangement under /etc/rc.d/. /sbin/chkconfig --list lists all the services controlled by chkconfig and whether they are on/off for each runlevel. Setting a service A controlled by chkconfig, for levels X, Y and Z is as simple as /etc/chkconfig --level XYZ A

[edit] SUSE Linux

SUSE uses a similar setup to Red Hat:

• 0 - Halt
• 1 - Single
• 2 - Full multi-user with no networking
• 3 - Full multi-user without display manager
• 4 - Not used/User definable
• 5 - Full multi-user with display manager
• 6 - Reboot

An introduction to services, runlevels, and rc.d scripts By Mark Alexander Bain

January 11, 2006 | Linux.com

What's the first thing that you do once you've logged onto Linux? Is it to manually start up a processes such as Apache or MySQL, or even start your network connection? Or do you have to stop applications that have started up without your telling them to, and which are overloading your machine? If you have unwanted processes starting at boot time, or find yourself starting necessary services manually, let's make your life a little bit easier by introducing you the world of Linux services.

A Linux service is an application (or set of applications) that runs in the background waiting to be used, or carrying out essential tasks. I've already mentioned a couple of typical ones (Apache and MySQL). You will generally be unaware of services until you need them.

How can you tell what services are running, and more importantly, how can you set up your own?

System V vs. BSD

In this article I'm dealing with System V (derived from AT&T System V) based distributions. This is the most common Linux init system. Another is based on BSD (Berkeley Software Distribution). What's the difference between the two? Basically BSD doesn't have any runlevels. This means that System V gives a lot more flexibility to a system administrator. Most Linux distros put startup scripts in the rc subdirectories (rc1.d, rc2.d, etc.), whereas BSD systems house the system scripts in /etc/rc.d. Slackware's init setup is similar to BSD systems, though Slackware does have runlevels and has had System V compatibility since Slackware 7.

Let's start by looking at how the system is set up, and in particular at the directory /etc/rc.d. Here you will find either a set of files named rc.0, rc.1, rc.2, rc.3, rc.4, rc.5, and rc.6, or a set of directories named rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, and rc6.d. You will also find a file named /etc/inittab. The system uses these files (and/or directories) to control the services to be started.

If you look in the file /etc/inittab you will see something like:

id:5:initdefault:

l0:0:wait:/etc/rc.d/rc.0
l6:6:wait:/etc/rc.d/rc.6
x1:4:wait:/etc/rc.d/rc.4

The boot process uses these parameters to identify the default runlevel and the files that will be used by that runlevel. In this example, runlevel 4 is the default and the scripts that define runlevel 5 can be found in /etc/rc.d/rc.5.

And what is a runlevel? You might assume that this refers to different levels that the system goes through during a boot up. Instead, think of the runlevel as the point at which the system is entered. Runlevel 1 is the most basic configuration (simple single user access using an text interface), while runlevel 5 is the most advanced (multi-user, networking, and a GUI front end). Runlevels 0 and 6 are used for halting and rebooting the system.

There are, however, differences between Linux distributions. For instance, Fedora uses runlevel 5 for X-based logins, whereas Slackware uses runlevel 4 to do the same job. Therefore, you should check your documentation before making any changes. This table shows a generic list of configurations (and some examples of different distros) taken from Linux - The Complete Reference (R.Peterson, Osbourne/McGraw-Hill).

Run Level Generic Fedora Core Slackware Debian 0 Halt Halt Halt Halt 1 Single-user mode Single-user mode Single-user mode Single-user mode 2 Basic multi-user mode (without networking) User definable (Unused) User definable - configured the same as runlevel 3 Multi-user mode 3 Full (text based) multi-user mode Multi-user mode Multi-user mode - default Slackware runlevel 4 Not used Not used X11 with KDM/GDM/XDM (session managers) Multi-user mode 5 Full (GUI based) multi-user mode Full multi-user mode (with an X-based login screen) - default runlevel User definable - configured the same as runlevel 3 Multi-user mode 6 Reboot Reboot Reboot Reboot

As you can see there are slight (but important) differences between Linux distributions. One thing is common between them -- if you want to change the default level, you must edit /etc/initab. You will need to be root or use sudo to edit this file, naturally.

Why would you want to change the runlevel? Normally you will only use full GUI or text multi-user mode -- runlevels 4 or 5. You'd only want runlevels 1 or 2 if you have some system problems and you want the most basic access. Runlevels 0 and 6 should never be used as a default (for obvious reasons -- you don't want the system to shutdown or reboot as soon as you turn it on). You can, of course, change mode whilst the system is running. Type init followed by the required runlevel e.g.:

init 6

This will reboot the system.

The boot process, or to be more accurate the init command, will decide the runlevel to select (in the example above it's 4) and from that will decide the rc.d script files to be run. In this case either the file /etc/rc.d/rc.4 or any files in the directory /etc/rc.d/rc4.d. Let's look at an example rc.d script file. Here's the default rc.4 file for Slackware 10.2:

# Try to use GNOME's gdm session manager:
if [ -x /usr/bin/gdm ]; then
  exec /usr/bin/gdm -nodaemon
fi

# Not there?  OK, try to use KDE's KDM session manager:
if [ -x /opt/kde/bin/kdm ]; then
  exec /opt/kde/bin/kdm -nodaemon
fi

# If all you have is XDM, I guess it will have to do:
if [ -x /usr/X11R6/bin/xdm ]; then
  exec /usr/X11R6/bin/xdm -nodaemon
fi

A quick guide to the boot process

When you boot your computer, the first thing that it will do is load the bootloader -- either GRUB or LILO in most cases. The bootloader will then load the Linux kernel -- the core operating system. Next, a process called init starts. This process reads the file /etc/inittab to establish the runlevel to use. The runlevel is the start mode for the computer. Once init knows the runlevel it will look for the appropriate files or directories as defined in /etc/initab. Init will then either run the script files defined by /etc/initab, or run the script files in the directories defined by /etc/initab (depending on the set up of your system). Finally, init will present you with the logon mode that you've selected.

As you would expect, since runlevel 4 is the Slackware X11 mode, the commands are all concerned with the setting up of the graphical interface.

In the other distros (such as Fedora and Debian) you'll find that the scripts to be run are actually symbolic links to files in the directory /etc/init.d -- the central repository for all startup scripts. So all you have to do is to write your startup script, place it in /etc/init.d, and then create a symbolic link to it from the appropriate runlevel directory (or runlevel file, if that's what your system uses).

For example, runlevel 2 is the default runlevel for Debian in non-GUI mode. If you're running Apache 2 on Debian, you'd find an init script for Apache 2 under /etc/init.d called apache2. A symlink, S91apache2, points to /etc/init.d/apache2 from /etc/rc2.d -- this tells init to start Apache 2 in runlevel 2, but only after other services with lower S numbers.

When the system is shut down, there is another symlink in the /etc/rc0.d and /etc/rc6.d directories (halt and reboot, respectively) that starts with a K instead of an S, which tells init to shut down the process.

If this all still sounds a bit too complicated, you can instead simply make use of the /etc/rc.d/rc.local file. This script file is run once, before all other scripts have run but before the logon prompt appears. By default it looks something like:

#!/bin/bash
#
# /etc/rc.local - run once at boot time
# Put any local setup commands in here:

You can append your instructions onto the end of the file by defining another script to be run:

/root/bin/start_bb

Or you can modify rc.local by adding the commands themselves:

modprobe -r uhci
modprobe usb-uhci
eciadsl-start
iptable -F
iptables -A INPUT -i ppp0 -p tcp --syb -j DROP
netdate time.nist.gov

Here a USB modem is initialized, a connection set up to a broadband network, some basic security is set up, and then the local time is synchronized with a time server. You can also start Apache or MySQL:

apachectl start
echo "/usr/bin/mysqld_safe &" | su mysql

Note that some distros, such as Debian, do not use rc.local for startup scripts. See the Debian FAQ if you'd like to add startup scripts for Debian or Debian-derived distros.

One final thought -- in addition to startup scripts (for rc.local), try to remember to write close-down scripts to be added to rc.0 and rc.6. This ensures that your services are shut down neatly and not left in strange states when the system halts.

About shutting down -- how do you stop a service from starting when you reboot? It's just the reverse of what we've already looked at. Either edit the relevant runlevel file (comment the lines out rather than removing them) or remove the link from the runlevel directory. Note that it may not be necessary to do this manually, as many distros include tools to manage services. For example, Red Hat and Fedora use chkconfig, while Debian uses update-rc.d.

From this brief discussion, I hope you can see how useful rc.d scripts can be when it comes to controlling the services to be run on your PC. You can now add your own as required, as well as look at existing ones that you may not require and which are slowing down your logon or overloading your PC.

Linux Setup - F*king Beagle on Suse 10

F**king Beagle on Suse 10

Ron Albright 2006-03-25, 10:19 am How do I stop it, forever. I figured out how to kill the Beagle process that were taking up 500MB of my memory but there are still process starting every night by root and suing to another uid and they never exit. What is starting these things and how do I stop them? I can't find anything in the rc scripts or crontabs. Short of uninstalling it where can I find information on what's starting anything related to Beagle? I can find all kinds of information on installing and using it but nothing on stopping it. Any pointers would be greatly appreciated.

Nico Kadel-Garcia 2006-03-25, 10:19 am Ron Albright wrote: > How do I stop it, forever. I figured out how to kill the Beagle > process that were taking up 500MB of my memory but there are still > process starting every night by root and suing to another uid and > they never exit. What is starting these things and how do I stop > them? I can't find anything in the rc scripts or crontabs. Short of > uninstalling it where can I find information on what's starting > anything related to Beagle? I can find all kinds of information on > installing and using it but nothing on stopping it. Any pointers > would be greatly appreciated. rpm -e beagle? It seems to be an RPM package.

J. Clarke 2006-03-25, 10:19 am Ron Albright wrote: > How do I stop it, forever. I figured out how to kill the Beagle process > that were taking up 500MB of my memory but there are still process > starting every night by root and suing to another uid and they never exit. > What is starting these things and how do I stop them? I can't find > anything in the rc scripts or crontabs. Short of uninstalling it where can > I find information on what's starting anything related to Beagle? I can > find all kinds of information on installing and using it but nothing on > stopping it. Any pointers would be greatly appreciated. You need to find what is starting beagled and either induce it to quit starting beagled or have it start beagled with "beagled --disable-scheduler". Once beagled is running it does its own scheduling. Best thing to do about it IMO is remove the whole package. -- --John to email, dial "usenet" and validate (was jclarke at eye bee em dot net)

Recommended Links

• Cool Solutions Creating Custom init Scripts
• HOWTO Make an rc script - Gentoo Linux Wiki
• Chapter 7 Customizing the boot process
• Lecture 3More on System Startup
• The SuSE Linux Boot Concept

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019