The idea of runlevels came from System V and is pretty neat idea, which
unfortunately was made more complex then necessary in recent Linux distributions
(especially Suse, Red Hat is more reasonable).
In its initial form it allows, without increasing complexity of the system
, substantial flexibility in defining set of running daemons for the one
of several "final" stages to which system can be booted. With runelvels
there can be multiple such states. This about it as a neat generalization
of MS DOS authoexec.bat file.
Each runlevel is defined by a set of daemons that it should be started
on entering this runlevel (and by extension a set of daemons that it need
to be shut down, when you exit this runlevel). In other words, each
runlevel is configured to start its specified services when starting and
to shut down its services when switching to a different runlevel.
Availability of different system states (runlevels), each with own set of running daemons can be used for recovery
and for optimizing system for running a particular application. This scheme
also provides an opportunity to set a default level to which system is booted.
As a side effect of this scheme you can change from one runlevel to another
dynamically without rebooting the system. This is another big plus of runlevel
as implemented in System V. In this scheme shutting down the system becomes
just a switch to a special (fake) runlevel.
Switching from higher runlevel to lower, for example from 5 to 3,
usually involves killing some daemons. And vise versa, switching
to high runlevel, for example from 3 to 5, involves starting some
daemons. But please note that notions or higher runlevels and lower
runlevels are human-defined. For init each runlevel is just a set
of daemons to kill plus a set of daemons to start. Numeric value of the
runlevel does not have any meaningful semantic in init. All runlevels
are treated atomically, completely independently of each other.
So you can (for example, as a joke) switch set of daemons on runlevel
5 to runlevel 3 and vise versa (by renaming the directories) and init will
eat this change as if this is what mother ordered. Urban legend that
Unix enters lower runlevels before reaching specified does not have any
real ground. It is just a myth.
For Unix OS runlevels do
not have any meaningful order. They are treated by OS atomically,
completely independently of each other. Urban legend that
Unix enters lower runlevels before reaching specified does not
have any real ground. It is just a myth.
Typically System V based flavors of Unix has the following four runlevels
defined:
Single user,
Multi-user without networking,
Full multiuser
Full multi-user with X11.
Meaning of
runlevels differs between various Linux flavors. There are two big camp:
Red Hat and its
derivatives (Oracle Linux, CentOS, Academic Linux, Suse, etc). They uses run levels in more or less "classic"
Unix way.
Ubuntu uses single level 2 which is similar to level 5 in Red
Hat. The only other flavor of Unix with the same perverted scheme is AIX
:-)
Runlevels in Red Hat, Suse and all other members of Red Hat family:
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
In addition two "pseudo-runlevels ( 0 (halt) and 6 (reboot) in linux)
are assigned for shutting system down and rebooting it. So we have
4+2=6 different runlevels. Sometimes (in Solaris) level S is defined for runlevel
that does not run any init scripts. As some levels are not used and you
can define your own (see below).
Root user can switch from any runlevel to any. Switching to the single
user mode and back to multi-user with networking is equivalent to "soft
reboot" as it restarts all major daemons and is much quicker then full reboot
of the server.
Switching
to the single user mode and back to multi-user with networking
or multi user with X11 is equivalent to "soft reboot" as it
restarts all major daemons and is much quicker then full reboot
of the server.
While both Solaris and Linux are based on System V, Linux uses different
set of runlevels then Solaris. Moreover meaning of runlevels differs between
various Linux flavors. There are two big camps:
Red Hat and its derivatives (Oracle Linux, CentOS, Academic
Linux, Suse, etc). They uses run levels in more or less "classic" Unix
System V way. Here are Runlevels in Red Hat and its derivatives
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 X11 and display
manager
6 - Reboot
Debian, Ubuntu and its derivative (Kibuntu, etc) uses single level
2 which is similar to level 5 in Red Hat. This is less flexible scheme
that System V inspired scheme. The only other flavor of Unix with
the same perverted scheme is AIX :-)
There are multiple directories involved in storage of init scripts. There
is one directory that stores the scripts, called /etc/init.d. And there
are additional directories, one for each runlevel (/etc/rc.0.d, /etc/rc1.d,
... /etc/rc6.d) which stores links to those scripts. Links can be of two
types:
K-scripts - symbolic links to the init script which start
with capital K and is used for killing the daemon ( e.g. myscript) by
executing stop command for particular init script. There are called
kill-scripts or exit scripts. For example for script mydaemon
execution of K-script K09mydaemon is equivalent to command
/etc/init.d/myscript stop. After letter K there are two
digits (called priority) which determine order in which this script
is executed (all K scripts are executed in ascending order of their
names.)
S-Scripts - symbolic links to the init script which start
with capital S and are used for starting the particular daemon (or performing
some housekeeping function). For example, for script mydaemon
execution of K-script S99mydaemon is equivalent to command
/etc/init.d/myscript start. Naming structure for S-scripts
is the same as for K-scripts: after letter K there are two digits that
determine the order of execution.
Two sets of init scripts are involved in switching runlevels: K-scripts
from the runlevel on which we are currently running and S-scripts from a
new (target) runlevel. It is important to understand that there are two
runlevels involved in switching:
runlevel from which we switch. Let's call it l_from
runlevel to which we switch. Let's call it l_to
Simplifying the rc script which is responsible for changing runlevels
performs the following two operations.
All K-scripts that exist on the current runlevel l_from
are processed. For each K-script for which S-script does not exists
at the target runlevel l_to, the K-script from l_from
is executed.
Each S script that exist at target runlevel l_to is executed
In other words when you change the runlevel first stop scripts of the
current runlevel are launched, closing down some daemons running on the
current runlevel that are not necessary on a new runlevel (do not have S-script
defined for them). Then all start scripts of the new runlevel are run in
the order defined by their numeric priorities (lexographic order).
For example, the following occurs when changing from runlevel 3 to 5:
The administrator (root) enter the command init 5 which
tells init to change the current runlevel to 5.
The init consults its configuration file (/etc/inittab)
and determines it should start /etc/init.d/rc with the new
runlevel as a parameter.
Now rc calls all the stop scripts of the current runlevel,
but only those for which there is no start script in the new runlevel.
In this example, these are all the scripts that reside in /etc/init.d/rc3.d
(old runlevel was 3) and start with a K. The number following
K specifies the order to start, because there are some dependencies
to consider.
The last things to start are the start scripts of the new runlevel.
These are, in this example, in /etc/init.d/rc5.d and begin
with an S. The same procedure regarding the order in which
they are started is applied here.
When changing into the same runlevel as the current runlevel, init only
checks /etc/inittab for changes and starts the appropriate scripts.
The init command allows you to reboot computer using as a switch to runlevel 0. Here is an example:
# init 0
A shutdown command should generally be used instead as it prompts you
if your action is correct and can delay actual shutdown so that that user can
close their programs befors reboot; you can also specify interval before reboot or exact time when it should happen. By default the
command requires acknowledgement
(which can be cancelled using the -y switch). The -h switch forces the system to halt,
and the first argument tells it how long to wait before starting the shutdown process. minutes. For example (you can use the
word now intstead of 0):
# shutdown -hy 0
Broadcast message from root (pts/0) (Sat Nov 6 13:15:27 2004):
The system is going down for system halt NOW!
#
You can also use the init command to reboot the system immediately by entering
runlevel 6.
# init 6
The "reboot" command has the same effect, but it also sends a warning message
to all users.
# reboot
Broadcast message from root (pts/0) (Sat Nov 6 12:39:31 2004):
The system is going down for reboot NOW!
#
More graceful reboots can be done with the shutdown command using the -r switch
and specifying a delay. For example reboot with the delay of 10 minutes:
# shutdown -ry 10
Broadcast message from root (pts/0) (Sat Nov 6 13:26:39 2004):
The system is going DOWN for reboot in 10 minutes!
Broadcast message from root (pts/0) (Sat Nov 6 13:27:39 2004):
The system is going DOWN for reboot in 9 minutes!
...
...
...
Broadcast message from root (pts/0) (Sat Nov 6 13:36:39 2004):
The system is going down for reboot NOW!
Some activities require you to force the system to log off all users, third-party applications and networking so that only the
systems administrator has access to the system. This can be done by using the command
init 1. It is best to do this from the console, because if you do it
from a remote terminal session you'll be logged out.
# init 1
In this case there no prior warning to users. To broadcase a warning, you can run the shutdown
command with a delay in minutes as the only argument.
# shutdown 1
Broadcast message from root (pts/0) (Sat Nov 6 13:44:59 2004):
The system is going DOWN to maintenance mode in 1 minute!
Broadcast message from root (pts/0) (Sat Nov 6 13:45:59 2004):
The system is going down to maintenance mode NOW!
...
...
#
Entering Single-user Mode At The Grub Splash Screen
You can enter single user mode directly after turning on the power to your system.
The steps to do this are listed below.
1. Power on your system. Wait for the "Grub loading" message to appear and, depending
on your Linux distribution, get ready to hit either any key or the ESC key to enter
the grub boot menu.
Grub loading, please wait ...
Press ESC to enter the menu
or
Grub loading, please wait ...
Press any key to enter the menu
2. You will then get grub's main menu which will display a list of available
kernels. Use the arrow keys to scroll to your desired version of the kernel and
then press e for "edit".
Fedora Core (2.6.18-1.2239.fc5smp)
3. The kernel's boot menu will appear. Use the arrow keys to scroll to the "kernel"
line and then press e for "edit".
4. A grub edit prompt will appear. Use the arrow keys to move to the end of the
line and add the word "single" to the end, separated by a space. Change
grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/ single
5. Press enter to save your changes, and then b for "boot".
6. The system will
continue to boot, but will go straight to the root # prompt without first asking
for a username and password.
Reverting To Your Default runlevel From Single User Mode
The exit command forces the system to exit runlevel 1 and revert to the default
runlevel for the system. You can also use the init command (for example, init 3 and
init 5) to alter this default behavior:
Sometimes you might forget the root password, or the previous systems administrator
may move on to a new job without giving it to you. To do this by booting either directly to bash (see
Boot
Directly into a Shell)
or, if single mode is not password protected, to a single user mode. See Linux root password
recovery
Typically you can define new runlevel by copying /etc/rc5.d
or other already existing runlevel directories and then making the necessary
changes. There are two issues here:
If you define default runlevel incorrectly the server might be boot.
To avoid such a situation you would be usually better off to base
your runlevel on existing runlevel and than make changes gradually.
It is best to copy all links from the existing runlevel into new directory
and start adapting it one by one.
You might benefit from including a new runlevel into headers of
all init scripts ( chkconfig read those headers to determine affected
runlevels for operations on and off). That is necessary only if you
want to use chkconfig
to manage this level. This addition involves just one line and can be
done automatically by a simple Perl script.
Like in many other cases it make sense to leave existing single digit
runlevels as "system runlevels" and copy the content and then modify it
under a new, unused runlevel number (4, 7, 8, or 9). Here are some
possibilities that are connected with new runlevels:
New runlevel can use different
X11 environment (KDE instead of Gnome) and/or can just
add several daemon to existing runlevel without killing any. For example
you can have a separate runlevel for wireless networking.
You can create runlevel optimized for
particular application. For example, in Red Hate you
can create runlevel 4 which is by-and-large identical to level 5 but
has does not run anything that is not needed by particular application
(recent version of Rea Hat run large number of extra daemons which are
required only in particular case, for example if you have wireless networking,
added or removed hardware from the system, etc. You can also start different
version of some daemons, creating opportunity quickly change to older
version with a single command, if something go wrong. For example
you can run different versions of Apache and Oracle on those two levels.
You can define special runlevel to run
backups with minimal number of daemons. In this
case switch to a different runlevel can be done via cron, when backup
is starting and switch back when backup ends.
You can copy runlevel level 2 to runlevel 4 and delete networking,
which is sometimes nice for maintenance (traditionally level 2 was level
without networking, but linux distributions for some reason ignored
this tradition).
Sometimes instead of calling script that starts several products you
can incorporate each step as a separate init script. For example this
can be done with such products as Oracle Fusion and LDAP server, In this
case the start priorities for consequent steps should be sequential
The default runlevel for a system is specified in the
/etc/inittab file, which will
contain an entry such as id:3:initdefault:
if the system starts in runlevel 3, or
id:5:initdefault: if it starts
in runlevel 5.
There are three method of determining the current runlevel
who -r command:
# who -r
run-level 3 Aug 27 10:12 last=5
Using runlevel command
which produces essentially the same result but in a form of just two
numbers. Runlevel command retrieves information from the
/var/run/utmp to locate
the runlevel record.
The last method is not working in mainstream flavors of Linux (Red
Hat 4 & 5 and Suse 10 & 11) but is an interesting option. In some
versions of init the
environment variables RUNLEVEL and PREVLEVEL are populated and changed
with each change, similar to $PWD
and other system variables. In this case you can simply type:
One of the best ways to configure runlevels is to use an init-script
utility. These tools are designed to simplify the task of maintaining
files in the SysV init directory hierarchy and relieves system
administrators from having to directly manipulate the numerous symbolic
links in the subdirectories of /etc/rc.d/. Red Hat Enterprise Linux
provides three such utilities:
/sbin/chkconfig — The /sbin/chkconfig utility is a simple
command line tool for maintaining the /etc/rc.d/init.d/ directory
hierarchy.
Services Configuration Tool — [RHEL only] The graphical Services
Configuration Tool (system-config-services) program is a flexible
utility for configuring runlevels.
It might surprise you to know that if you
forget to flip the network interface card (NIC) switch to the ON position (shown in the image below) during
installation, your Red Hat-based system will boot with the NIC disconnected:
Image
Setting the NIC to the ON position during installation.
More Linux resources
But, don't worry, in this article I'll
show you how to set the NIC to connect on every boot and I'll show you how to disable/enable your NIC on demand.
If your NIC isn't enabled at startup, you
have to edit the
/etc/sysconfig/network-scripts/ifcfg-NIC_name
file,
where NIC_name is your system's NIC device name. In my case, it's enp0s3. Yours might be eth0, eth1, em1, etc.
List your network devices and their IP addresses with the
ip
addr
command:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:81:d0:2d brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:4e:69:84 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:4e:69:84 brd ff:ff:ff:ff:ff:ff
Note that my primary NIC (enp0s3) has no
assigned IP address. I have virtual NICs because my Red Hat Enterprise Linux 8 system is a VirtualBox virtual
machine. After you've figured out what your physical NIC's name is, you can now edit its interface configuration
file:
$ sudo vi /etc/sysconfig/network-scripts/ifcfg-enp0s3
and change the
ONBOOT="no"
entry
to
ONBOOT="yes"
as
shown below:
You don't need to reboot to start the NIC,
but after you make this change, the primary NIC will be on and connected upon all subsequent boots.
To enable the NIC, use the
ifup
command:
ifup enp0s3
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5)
Now the
ip
addr
command displays the enp0s3 device with an IP address:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:81:d0:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.64/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s3
valid_lft 86266sec preferred_lft 86266sec
inet6 2600:1702:a40:88b0:c30:ce7e:9319:9fe0/64 scope global dynamic noprefixroute
valid_lft 3467sec preferred_lft 3467sec
inet6 fe80::9b21:3498:b83c:f3d4/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:4e:69:84 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:4e:69:84 brd ff:ff:ff:ff:ff:ff
To disable a NIC, use the
ifdown
command.
Please note that issuing this command from a remote system will terminate your session:
ifdown enp0s3
Connection 'enp0s3' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5)
That's a wrap
It's frustrating to encounter a Linux
system that has no network connection. It's more frustrating to have to connect to a virtual KVM or to walk up to
the console to fix it. It's easy to miss the switch during installation, I've missed it myself. Now you know how
to fix the problem and have your system network-connected on every boot, so before you drive yourself crazy with
troubleshooting steps, try the
ifup
command
to see if that's your easy fix.
When you press a machine's power button, the boot process starts with a hardware-dependent
mechanism that loads a bootloader . The bootloader software finds the kernel on the disk
and boots it. Next, the kernel mounts the root filesystem and executes an init
process.
This process sounds simple, and it might be what actually happens on some Linux systems.
However, modern Linux distributions have to support a vast set of use cases for which this
procedure is not adequate.
First, the root filesystem could be on a device that requires a specific driver. Before
trying to mount the filesystem, the right kernel module must be inserted into the running
kernel. In some cases, the root filesystem is on an encrypted partition and therefore needs a
userspace helper that asks the passphrase to the user and feeds it to the kernel. Or, the root
filesystem could be shared over the network via NFS or iSCSI, and mounting it may first require
configured IP addresses and routes on a network interface.
To overcome these issues, the bootloader can pass to the kernel a small filesystem image
(the initrd) that contains scripts and tools to find and mount the real root filesystem. Once
this is done, the initrd switches to the real root, and the boot continues as usual.
The
dracut infrastructure
On Fedora and RHEL, the initrd is built through dracut . From its home page , dracut is "an event-driven initramfs
infrastructure. dracut (the tool) is used to create an initramfs image by copying tools and
files from an installed system and combining it with the dracut framework, usually found in
/usr/lib/dracut/modules.d ."
A note on terminology: Sometimes, the names initrd and initramfs are used
interchangeably. They actually refer to different ways of building the image. An initrd is an
image containing a real filesystem (for example, ext2) that gets mounted by the kernel. An
initramfs is a cpio archive containing a directory tree that gets unpacked as a tmpfs.
Nowadays, the initrd images are deprecated in favor of the initramfs scheme. However, the
initrd name is still used to indicate the boot process involving a temporary
filesystem.
Kernel command-line
Let's revisit the NFS-root scenario that was mentioned before. One possible way to boot via
NFS is to use a kernel command-line containing the root=dhcp argument.
The kernel command-line is a list of options passed to the kernel from the bootloader,
accessible to the kernel and applications. If you use GRUB, it can be changed by pressing the e
key on a boot entry and editing the line starting with linux .
The dracut code inside the initramfs parses the kernel command-line and starts DHCP on all
interfaces if the command-line contains root=dhcp . After obtaining a DHCP lease,
dracut configures the interface with the parameters received (IP address and routes); it also
extracts the value of the root-path DHCP option from the lease. The option carries an NFS
server's address and path (which could be, for example, 192.168.50.1:/nfs/client
). Dracut then mounts the NFS share at this location and proceeds with the boot.
If there is no DHCP server providing the address and the NFS root path, the values can be
configured explicitly in the command line:
The first can be used for automatic configuration (DHCP or IPv6 SLAAC), and the second for
static configuration or a combination of automatic and static. Here some examples:
Note that if you pass an ip= option, but dracut doesn't need networking to
mount the root filesystem, the option is ignored. To force network configuration without a
network root, add rd.neednet=1 to the command line.
You probably noticed that among automatic configuration methods, there is also ibft .
iBFT stands for iSCSI Boot Firmware Table and is a mechanism to pass parameters about iSCSI
devices from the firmware to the operating system. iSCSI (Internet Small Computer Systems
Interface) is a protocol to access network storage devices. Describing iBFT and iSCSI is
outside the scope of this article. What is important is that by passing ip=ibft to
the kernel, the network configuration is retrieved from the firmware.
Dracut also supports adding custom routes, specifying the machine name and DNS servers,
creating bonds, bridges, VLANs, and much more. See the dracut.cmdline man page for more
details.
Network modules
The dracut framework included in the initramfs has a modular architecture. It comprises a
series of modules, each containing scripts and binaries to provide specific functionality. You
can see which modules are available to be included in the initramfs with the command
dracut --list-modules .
At the moment, there are two modules to configure the network: network-legacy
and network-manager . You might wonder why different modules provide the same
functionality.
network-legacy is older and uses shell scripts calling utilities like
iproute2 , dhclient , and arping to configure
interfaces. After the switch to the real root, a different network configuration service runs.
This service is not aware of what the network-legacy module intended to do and the
current state of each interface. This can lead to problems maintaining the state across the
root switch boundary.
A prominent example of a state to be kept is the DHCP lease. If an interface's address
changed during the boot, the connection to an NFS share would break, causing a boot
failure.
To ensure a seamless transition, there is a need for a mechanism to pass the state between
the two environments. However, passing the state between services having different
configuration models can be a problem.
The network-manager dracut module was created to improve this situation. The
module runs NetworkManager in the initrd to configure connection profiles generated from the
kernel command-line. Once done, NetworkManager serializes its state, which is later read by the
NetworkManager instance in the real root.
Fedora 31 was the first distribution to switch to network-manager in initrd by
default. On RHEL 8.2, network-legacy is still the default, but
network-manager is available. On RHEL 8.3, dracut will use
network-manager by default.
Enabling a different network module
While the two modules should be largely compatible, there are some differences in behavior.
Some of those are documented in the nm-initrd-generator man page. In general, it
is suggested to use the network-manager module when NetworkManager is enabled.
To rebuild the initrd using a specific network module, use one of the following
commands:
The --regenerate-all option also rebuilds all the initramfs images for the
kernel versions found on the system.
The network-manager dracut module
As with all dracut modules, the network-manager module is split into stages
that are called at different times during the boot (see the dracut.modules man page for more
details).
The first stage parses the kernel command-line by calling
/usr/libexec/nm-initrd-generator to produce a list of connection profiles in
/run/NetworkManager/system-connections . The second part of the module runs after
udev has settled, i.e., after userspace has finished handling the kernel events for devices
(including network interfaces) found in the system.
When NM is started in the real root environment, it registers on D-Bus, configures the
network, and remains active to react to events or D-Bus requests. In the initrd, NetworkManager
is run in the configure-and-quit=initrd mode, which doesn't register on D-Bus
(since it's not available in the initrd, at least for now) and exits after reaching the
startup-complete event.
The startup-complete event is triggered after all devices with a matching connection profile
have tried to activate, successfully or not. Once all interfaces are configured, NM exits and
calls dracut hooks to notify other modules that the network is available.
Note that the /run/NetworkManager directory containing generated connection
profiles and other runtime state is copied over to the real root so that the new NetworkManager
process running there knows exactly what to do.
Troubleshooting
If you have network issues in dracut, this section contains some suggestions for
investigating the problem.
The first thing to do is add rd.debug to the kernel command-line, enabling debug logging in
dracut. Logs are saved to /run/initramfs/rdsosreport.txt and are also available in
the journal.
If the system doesn't boot, it is useful to get a shell inside the initrd environment to
manually check why things aren't working. For this, there is an rd.break command-line argument.
Note that the argument spawns a shell when the initrd has finished its job and is about to give
control to the init process in the real root filesystem. To stop at a different stage of dracut
(for example, after command-line parsing), use the following argument:
The initrd image contains a minimal set of binaries; if you need a specific tool at the
dracut shell, you can rebuild the image, adding what is missing. For example, to add the ping
and tcpdump binaries (including all their dependent libraries), run:
# dracut -f --install "ping tcpdump"
and then optionally verify that they were included successfully:
If you are familiar with NetworkManager configuration, you might want to know how a given
kernel command-line is translated into NetworkManager connection profiles. This can be useful
to better understand the configuration mechanism and find syntax errors in the command-line
without having to boot the machine.
The generator is installed in /usr/libexec/nm-initrd-generator and must be
called with the list of kernel arguments after a double dash. The --stdout option
prints the generated connections on standard output. Let's try to call the generator with a
sample command line:
$ /usr/libexec/nm-initrd-generator --stdout -- \
ip=enp1s0:dhcp:00:99:88:77:66:55 rd.peerdns=0
802-3-ethernet.cloned-mac-address: '99:88:77:66:55' is not a valid MAC
address
In this example, the generator reports an error because there is a missing field for the MTU
after enp1s0 . Once the error is corrected, the parsing succeeds and the tool prints out the
connection profile generated:
Note how the rd.peerdns=0 argument translates into the ignore-auto-dns=true property, which
makes NetworkManager ignore DNS servers received via DHCP. An explanation of NetworkManager
properties can be found on the nm-settings man page.
The NetworkManager dracut module is enabled by default in Fedora and will also soon be
enabled on RHEL. It brings better integration between networking in the initrd and
NetworkManager running in the real root filesystem.
While the current implementation is working well, there are some ideas for possible
improvements. One is to abandon the configure-and-quit=initrd mode and run
NetworkManager as a daemon started by a systemd service. In this way, NetworkManager will be
run in the same way as when it's run in the real root, reducing the code to be maintained and
tested.
To completely drop the configure-and-quit=initrd mode, NetworkManager should
also be able to register on D-Bus in the initrd. Currently, dracut doesn't have any module
providing a D-Bus daemon because the image should be minimal. However, there are already
proposals to include it as it is needed to implement some new features.
With D-Bus running in the initrd, NetworkManager's powerful API will be available to other
tools to query and change the network state, unlocking a wide range of applications. One of
those is to run nm-cloud-setup in the initrd. The service, shipped in the
NetworkManager-cloud-setup Fedora package fetches metadata from cloud providers'
infrastructure (EC2, Azure, GCP) to automatically configure the network.
I can't figure out how to disable the startup graphic in centos 7 64bit.
In centos 6 I always did it by removing "rhgb quiet" from /boot/grub/grub.conf but there is no
grub.conf in centos 7. I also tried yum remove rhgb but that wasn't present either.
<moan> I've never understood why the devs include this startup graphic, I see loads of
users like me who want a text scroll instead.</moan>
Thanks for any help.
I can't figure out how to disable the startup graphic in centos 7 64bit.
In centos 6 I always did it by removing "rhgb quiet" from /boot/grub/grub.conf but there is no
grub.conf in centos 7. I also tried yum remove rhgb but that wasn't present either.
<moan> I've never understood why the devs include this startup graphic, I see loads of
users like me who want a text scroll instead.</moan>
Thanks for any help. Top
The file to amend now is /boot/grub2/grub.cfg and also
/etc/default/grub. If you only amend the defaults file then you need to run grub2-mkconfig -o
/boot/grub2/grub.cfg afterwards to get a new file generated but you can also edit the grub.cfg
file directly though your changes will be wiped out next kernel install if you don't also edit
the 'default' file. CentOS 6 will die in November 2020 - migrate sooner rather than later!
CentOS 5 has been EOL for nearly 3 years and should no longer be used for anything!
Full time Geek, part time moderator. Use the FAQ Luke Top
The preferred method to do this is using the command plymouth-set-default-theme.
If you enter this command, without parameters, as user root you'll see something like
>plymouth-set-default-theme
charge
details
text
This lists the themes installed on your computer. The default is 'charge'. If you want to
see the boot up details you used to see in version 6, try
>plymouth-set-default-theme details
Followed by the command
>dracut -f
Then reboot.
This process modifies the boot loader so you won't have to update your grub.conf file
manually everytime for each new kernel update.
There are numerous themes available you can download from CentOS or in general. Just google
'plymouth themes' to see other possibilities, if you're looking for graphics type screens.
Top
Editing /etc/default/grub to remove rhgb quiet makes it permanent too.
CentOS 6 will die in November 2020 - migrate sooner rather than later!
CentOS 5 has been EOL for nearly 3 years and should no longer be used for anything!
Full time Geek, part time moderator. Use the FAQ Luke Top
I tried both TrevorH's and LarryG's methods, and LarryG wins.
Editing /etc/default/grub to remove "rhgb quiet" gave me the scrolling boot messages I want,
but it reduced maxmum display resolution (nouveau driver) from 1920x1080 to 1024x768! I put
"rhgb quiet" back in and got my 1920x1080 back.
Then I tried "plymouth-set-default-theme details; dracut -f", and got verbose booting
without loss of display resolution. Thanks LarryG! Top
I have used this mod to get back the details for grub boot, thanks to
all for that info.
However when I am watching it fills the page and then rather than scrolling up as it did in
V5 it blanks and starts again at the top. Of course there is FAIL message right before it
blanks that I want to see and I can't slam the Scroll Lock fast
enough to catch it. Anyone know how to get the details to scroll up rather than the blank and
re-write?
Yeah the scroll lock/ctrl+q/ctrl+s will not work with systemd you can't pause the
screen like you used to be able to (it was a design choice, due to parallel daemon launching,
apparently).
If you do boot, you can always use journalctrl to view the logs.
In Fedora you can use journalctl --list-boots to list boots (not 100% sure about CentOS 7.x -
perhaps in 7.1 or 7.2?). You can also use things like journalctl --boot=-1 (the last boot), and
parse the log at you leisure. Top
aks wrote: Yeah the scroll lock/ctrl+q/ctrl+s will not work with systemd you
can't pause the screen like you used to be able to (it was a design choice, due to parallel
daemon launching, apparently).
If you do boot, you can always use journalctrl to view the logs.
In Fedora you can use journalctl --list-boots to list boots (not 100% sure about CentOS 7.x -
perhaps in 7.1 or 7.2?). You can also use things like journalctl --boot=-1 (the last boot),
and parse the log at you leisure.
Thanks for the followup aks. Actually I have found that the Scroll Lock
does pause (Ctrl-S/Q not) but it all goes by so fast that I'm not fast enough to stop it
before the screen blanks and then starts writing again. What I am really wondering is how to
get the screen to scroll up when it gets to the bottom of the screen rather than blanking and
starting to write again at the top. That is annoying!
Lately, booting Ubuntu on my desktop has become seriously slow. We're talking two minutes. It
used to take 10-20 seconds. Because of plymouth, I can't see what's going on. I would like to
deactivate it, but not really uninstall it. What's the quickest way to do that? I'm using
Precise, but I suspect a solution for 11.10 would work just as well.
Easiest quick fix is to edit the grub line as you boot.
Hold down the shift key so you see the menu. Hit the e key to edit
Edit the 'linux' line, remove the 'quiet' and 'splash'
To disable it in the long run
Edit /etc/default/grub
Change the line – GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to
GRUB_CMDLINE_LINUX_DEFAULT=""
And then update grub
sudo update-grub
Panther , 2016-10-27 15:43:04
Removing quiet and splash removes the splash, but I still only have a purple screen with no
text. What I want to do, is to see the actual boot messages. – Jo-Erlend Schinstad Jan 25 '12 at
22:25
Tuminoid ,
How about pressing CTRL+ALT+F2 for console allowing you to see whats going on..
You can go back to GUI/Plymouth by CTRL+ALT+F7 .
Don't have my laptop here right now, but IIRC Plymouth has upstart job in
/etc/init , named plymouth???.conf, renaming that probably achieves what you
want too more permanent manner.
Before EFI, the standard boot process
for virtually all PC systems was called "MBR", for Master Boot Record; today you are likely to
hear it referred to as "Legacy Boot". This process depended on using the first physical block
on a disk to hold some information needed to boot the computer (thus the name Master Boot
Record); specifically, it held the disk address at which the actual bootloader could be found,
and the partition table that defined the layout of the disk. Using this information, the PC
firmware could find and execute the bootloader, which would then bring up the computer and run
the operating system.
This system had a number of rather obvious weaknesses and shortcomings. One of the biggest
was that you could only have one bootable object on each physical disk drive (at least as far
as the firmware boot was concerned). Another was that if that first sector on the disk became
corrupted somehow, you were in deep trouble.
Over time, as part of the Extensible Firmware Interface, a new approach to boot
configuration was developed. Rather than storing critical boot configuration information in a
single "magic" location, EFI uses a dedicated "EFI boot partition" on the desk. This is a
completely normal, standard disk partition, the same as which may be used to hold the operating
system or system recovery data.
The only requirement is that it be FAT formatted, and it should have the boot and
esp partition flags set (esp stands for EFI System Partition). The specific data and
programs necessary for booting is then kept in directories on this partition, typically in
directories named to indicate what they are for. So if you have a Windows system, you would
typically find directories called 'Boot' and 'Microsoft' , and perhaps one named for the
manufacturer of the hardware, such as HP. If you have a Linux system, you would find
directories called opensuse, debian, ubuntu, or any number of others depending on what
particular Linux distribution you are using.
It should be obvious from the description so far that it is perfectly possible with the EFI
boot configuration to have multiple boot objects on a single disk drive.
Before going any further, I should make it clear that if you install Linux as the only
operating system on a PC, it is not necessary to know all of this configuration information in
detail. The installer should take care of setting all of this up, including creating the EFI
boot partition (or using an existing EFI boot partition), and further configuring the system
boot list so that whatever system you install becomes the default boot target.
If you were to take a brand new computer with UEFI firmware, and load it from scratch with
any of the current major Linux distributions, it would all be set up, configured, and working
just as it is when you purchase a new computer preloaded with Windows (or when you load a
computer from scratch with Windows). It is only when you want to have more than one bootable
operating system – especially when you want to have both Linux and Windows on the same
computer – that things may become more complicated.
The problems that arise with such "multiboot" systems are generally related to getting the
boot priority list defined correctly.
When you buy a new computer with Windows, this list typically includes the Windows
bootloader on the primary disk, and then perhaps some other peripheral devices such as USB,
network interfaces and such. When you install Linux alongside Windows on such a computer, the
installer will add the necessary information to the EFI boot partition, but if the boot
priority list is not changed, then when the system is rebooted after installation it will
simply boot Windows again, and you are likely to think that the installation didn't work.
There are several ways to modify this boot priority list, but exactly which ones are
available and whether or how they work depends on the firmware of the system you are using, and
this is where things can get really messy. There are just about as many different UEFI firmware
implementations as there are PC manufacturers, and the manufacturers have shown a great deal of
creativity in the details of this firmware.
First, in the simplest case, there is a software utility included with Linux called
efibootmgr that can be used to modify, add or delete the boot priority list. If this
utility works properly, and the changes it makes are permanent on the system, then you would
have no other problems to deal with, and after installing it would boot Linux and you would be
happy. Unfortunately, while this is sometimes the case it is frequently not. The most common
reason for this is that changes made by software utilities are not actually permanently stored
by the system BIOS, so when the computer is rebooted the boot priority list is restored to
whatever it was before, which generally means that Windows gets booted again.
The other common way of modifying the boot priority list is via the computer BIOS
configuration program. The details of how to do this are different for every manufacturer, but
the general procedure is approximately the same. First you have to press the BIOS configuration
key (usually F2, but not always, unfortunately) during system power-on (POST). Then choose the
Boot item from the BIOS configuration menu, which should get you to a list of boot targets
presented in priority order. Then you need to modify that list; sometimes this can be done
directly in that screen, via the usual F5/F6 up/down key process, and sometimes you need to
proceed one level deeper to be able to do that. I wish I could give more specific and detailed
information about this, but it really is different on every system (sometimes even on different
systems produced by the same manufacturer), so you just need to proceed carefully and figure
out the steps as you go.
I have seen a few rare cases of systems where neither of these methods works, or at least
they don't seem to be permanent, and the system keeps reverting to booting Windows. Again,
there are two ways to proceed in this case. The first is by simply pressing the "boot
selection" key during POST (power-on). Exactly which key this is varies, I have seen it be F12,
F9, Esc, and probably one or two others. Whichever key it turns out to be, when you hit it
during POST you should get a list of bootable objects defined in the EFI boot priority list, so
assuming your Linux installation worked you should see it listed there. I have known of people
who were satisfied with this solution, and would just use the computer this way and have to
press boot select each time they wanted to boot Linux.
The alternative is to actually modify the files in the EFI boot partition, so that the
(unchangeable) Windows boot procedure would actually boot Linux. This involves overwriting the
Windows file bootmgfw.efi with the Linux file grubx64.efi. I have done this, especially in the
early days of EFI boot, and it works, but I strongly advise you to be extremely careful if you
try it, and make sure that you keep a copy of the original bootmgfw.efi file. Finally, just as
a final (depressing) warning, I have also seen systems where this seemed to work, at least for
a while, but then at some unpredictable point the boot process seemed to notice that something
had changed and it restored bootmgfw.efi to its original state – thus losing the Linux
boot configuration again. Sigh.
So, that's the basics of EFI boot, and how it can be configured. But there are some
important variations possible, and some caveats to be aware of.
There are several different applications available for free use which will allow you to flash ISO images to USB drives. In this
example, we will use Etcher. It is a free and open-source utility for flashing images to SD cards & USB drives and supports Windows,
macOS, and Linux.
Head over to the Etcher downloads page , and download the
most recent Etcher version for your operating system. Once the file is downloaded, double-click on it and follow the installation
wizard.
Creating Bootable Linux USB Drive using Etcher is a relatively straightforward process, just follow the steps outlined below:
Connect the USB flash drive to your system and Launch Etcher.
Click on the Select image button and locate the distribution .iso file.
If only one USB drive is attached to your machine, Etcher will automatically select it. Otherwise, if more than one SD cards
or USB drives are connected make sure you have selected the correct USB drive before flashing the image.
It's a important topic for Linux admin (such a wonderful topic) so, everyone must be aware of this and practice how to use this in
the efficient way.
In Linux, whenever we install any packages which has services or daemons. By default all the services "init & systemd" scripts
will be added into it but it wont enabled.
Hence, we need to enable or disable the service manually if it's required. There are three major init systems are available in
Linux which are very famous and still in use.
What is init System?
In Linux/Unix based operating systems, init (short for initialization) is the first process that started during the system boot
up by the kernel.
It's holding a process id (PID) of 1. It will be running in the background continuously until the system is shut down.
Init looks at the /etc/inittab file to decide the Linux run level then it starts all other processes & applications
in the background as per the run level.
BIOS, MBR, GRUB and Kernel processes were kicked up before hitting init process as part of Linux booting process.
Below are the available run levels for Linux (There are seven runlevels exist, from zero to six).
0: halt
1: Single user mode
2: Multiuser, without NFS
3: Full multiuser mode
4: Unused
5: X11 (GUI – Graphical User Interface)
: reboot
Below three init systems are widely used in Linux.
System V (Sys V)
Upstart
systemd
What is System V (Sys V)?
System V (Sys V) is one of the first and traditional init system for Unix like operating system. init is the first process that
started during the system boot up by the kernel and it's a parent process for everything.
Most of the Linux distributions started using traditional init system called System V (Sys V) first. Over the years, several replacement
init systems were released to address design limitations in the standard versions such as launchd, the Service Management Facility,
systemd and Upstart.
But systemd has been adopted by several major Linux distributions over the traditional SysV init systems.
What is Upstart?
Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping
them during shutdown and supervising them while the system is running.
It was originally developed for the Ubuntu distribution, but is intended to be suitable for deployment in all Linux distributions
as a replacement for the venerable System-V init.
It was used in Ubuntu from 9.10 to Ubuntu 14.10 & RHEL 6 based systems after that they are replaced with systemd.
What is systemd?
Systemd is a new init system and system manager which was implemented/adapted into all the major Linux distributions over the
traditional SysV init systems.
systemd is compatible with SysV and LSB init scripts. It can work as a drop-in replacement for sysvinit system. systemd is the
first process get started by kernel and holding PID 1.
It's a parant process for everything and Fedora 15 is the first distribution which was adapted systemd instead of upstart. systemctl
is command line utility and primary tool to manage the systemd daemons/services such as (start, restart, stop, enable, disable, reload
& status).
systemd uses .service files Instead of bash scripts (SysVinit uses). systemd sorts all daemons into their own Linux cgroups and
you can see the system hierarchy by exploring /cgroup/systemd file.
How to Enable or Disable Services on Boot Using chkconfig Commmand?
The chkconfig utility is a command-line tool that allows you to specify in which
runlevel to start a selected service, as well as to list all available services along with their current setting.
Also, it will allows us to enable or disable a services from the boot. Make sure you must have superuser privileges (either root
or sudo) to use this command.
All the services script are located on /etc/rd.d/init.d .
How to list All Services in run-level
The -–list parameter displays all the services along with their current status (What run-level the services are enabled
or disabled).
There are several ways to change runlevels. To make a permanent change,
you can edit /etc/inittab and change the default level as you just saw
above.
If you only need to bring the system up in a different runlevel for
one boot, you can do this. For example, suppose you just installed a
new kernel and need to build some kernel modules after the system booted
with the new kernel, but before you start the X Window System. You might
want to bring up the system in runlevel 3 to accomplish this. You do
this at boot time by editing the kernel line (GRUB) or adding a parameter
after the selected system name (LILO). Use a single digit to specify
the desired runlevel (3, in this case). We'll illustrate the process
with a GRUB example. Suppose your /boot/grub/menu.lst file contains
the stanza shown in Listing 2.
To bring this system up in runlevel 3, wait till the boot entries
are displayed, select this entry and enter 'e' to edit the entry. Depending
on your GRUB options, you may need to press a key to display the boot
entries and also enter 'p' and a password to unlock editing.
...
In this example, you should now see the root, kernel, and initrd
lines displayed. Move the cursor to the line starting with "kernel"
and press 'e' to edit the line.
... ... ...
Finally, move the cursor to the end of the line, and add a space
and the digit '3'. You may remove 'quiet' if you wish, or modify any
other parameters as needed.
... ... ...
Finally, press Enter to save the changes, then type
'b' to boot the system.
Note: The steps for doing this using LILO or GRUB2
differ from those for GRUB, but the basic principle of editing the way
the kernel is started remains. Even GRUB screens on other systems or
other distributions may look quite different to those shown here. Prompts
will usually be available to help you.
Once you have finished your setup work in runlevel 3, you will probably
want to switch to runlevel 5. Fortunately, you do not need to reboot
the system. You can use the telinit command to switch to
another runlevel. Use the runlevel command to show both
the previous runlevel and the current one. If the first output character
is 'N', the runlevel has not been changed since the system was booted.
Listing 3 illustrates verifying and changing the runlevel.
[root@pinguino ~]# runlevel
N 3
[root@pinguino ~]# telinit 5
After you enter telinit 5 you will see several messages
flash by and your display will switch to the configured graphical login
screen. Open a terminal window and verify that the runlevel has been
changed as shown in Listing 4.
If you use the ls command to display a long listing
of the telinit command, you will see that it really is
a symbolic link to the init command. We illustrate this
in Listing 5
The init executable knows whether it was called as
init or telinit and behaves accordingly. Since
init runs as PID 1 at boot time, it is also smart enough
to know when you subsequently invoke it using init rather
than telinit. If you do, it will assume you want it to
behave as if you had called telinit instead. For example,
you may use init 5 instead of telinit 5 to
switch to runlevel 5.
Immediately shuts down system and powers it off, if it can
1
Single user
Brings system to a bare essentials mode for maintenance
2
User-defined
Custom
3
Multi-user with console only
All services are running but X11
4
User-defined
Custom
5
Multi-user with display and console
All services are running including X11 (or GUI)
6
Reboot
Reboots the machine
What run-level am I?
Just like life, with an operating system you need to know where you
are now, in order to get to where you want to go next. If you are planning
on modifying your run-level, you need to first know what your current
run-level is. In order to do this, you can use one of two commands,
like so:
If we look at the output of who -r, we can tell that we are currently
running at run-level 3–which is multi-user, but console only.We can
also tell that we were previously running at run-level 5, which is multi-user
with console and X11 login.
Changing run-levels
Once you know what run-level you are at, it is very simple to change
to a different one. All you need to do is type: "init" followed by number
of the runlevel you would like to switch to. Here is an example of switching
to single user mode, or runlevel 1:
init 1
This command will change your system to single user mode, and it
will ask you for the root password. When you arrive in single user mode,
there are no services running, as this level it is most often used for
maintenance, backup, or recovery. Once you are in single user mode it
is quite common to enable, for example, network and NFS to backup your
operating system, like so:
service network start; service nfs start
When you are done with your work, type in the run-level you would
like to go to–perhaps run-level 5 which brings up the X11 login window:
init 5
Later in this article, we will write our own run-level and then use
it to script a maintenance operation.
Permanently changing the default run-level
While changing the runlevel manually is most common, sometimes it
is useful to change the default run-level from level 5 to level 3 permanently.
This can help conserve resources inside of, for example, a virtual machine.
You may also choose to define your own custom run-level, and wish to
make that the default.
You will need to edit /etc/inittab and change this line with your
favorite text editor:
id:5:initdefault:
Change '5′ to the run-level you wish your machine to be at when it
boots. To change the run-level so that it never loads the GUI on boot
would look like this:
id:3:initdefault:
Note:
A word of caution on editing /etc/inittab. It is very important
to keep /etc/inittab in version control, and/or keep a backup of
it when you are editing the file. If you make a change incorrectly
you can render your operating system unbootable.
Tip:
If you happen to get yourself in this pickle, there is a way out.
You can interrupt the Grub boot loader and press "A", and then append
the word "emergency" to the end of the kernel arguments. This will
boot the operating system without using init. Then, you can fix
what you altered by copying back the original version of /etc/inittab.
Creating your own run-level HACK
First, a word of caution. Do not do this on a production machine,
period! This section is a VERY dirty hack that you should only use on
a virtual machine you can experiment with, or a machine you don't mind
rebuilding.. It is always a good idea to do testing inside of a virtual
machine before doing something that could potentially render a box unbootable.
This is a very quick and dirty way to alter a run-level for the purposes
of learning, but perhaps you can get some ideas from it that can be
used in a more production-oriented way. Ideally, some of the readers
of this article will post some production quality hacks to creating
custom run levels.
cd to /etc/rc.d/rc4.d/
do a sanity check to make sure you are running Red Hat:
cat /etc/redhat-release
We have now copied the run-level scripts for single user mode into
our own custom run-level 4. We can hijack the the S99single script and
tell it to do something different. In this example, we are going to
write a custom Python script that gets forked to the background and
backs up the machine over rsync. Let's edit that file we copied:
vim /etc/rc.d/rc4.d/S99single
Change the last part of it to look like this:
# Now go to the single user level.
echo $"Telling INIT to go to single user mode."
echo "This is a custom code. Forking custom script"
/custom.py &
exec init -t1 S
We've inserted two lines. One echoes that we are forking off a custom
script. The second line forks a python script, shown below, that backs
up the machine via rsync. Note that this assumes you have set up ssh
keys on the remote backup server.
The main function runs a sleep command for 60 seconds, just to give
the single user mode scripts time to quiesce the box. Remember, this
script is forked to the background. Next, function single_user_backup
attempts to start network services and run rsync to remotely back up
the whole / volume to another server. This is obviously crude and there
will be lots of errors trying to back up /proc, for example, but it
give you an idea of how an automated backup could work with a custom
run-level. Finally, the machine gets called back to init 3, which is
console only multi-user mode.
Tip:
Again, this is just an idea for a backup script, but not one I would
actually run in production in my wildest dreams. One problem with
this technique is that because of symbolic links in run level 1,
we actually, changed run level 1 and our run level 4. This is not
acceptable, obviously, for any sane user, but it is acceptable as
a way to have fun with a disposable virtual machine!
If you can think of a more realistic backup script that would work
from a custom run-level, I would love to see it. Create a how to on
your blog, and then post a response to this article. Also, it would
interesting to see other things such as database backups and migration
done with custom run-levels as well. Leave a comment and let me know
what you'd do.
Running your own run-level
To run the newly created run-level, you only need to type:
init 4
You will then see the custom print statements we inserted. The machine
will sleep for 60 seconds, and then run the rsync backup.
Summary
This article covered quite a bit of ground in a short while. We went
over what a run-level was, how to tell what run-level you are at, how
to change run-levels, and, finally, how to make your own run-level with
custom, frankenstein quality, code. Hopefully, this showed you some
new tricks and spurs some ideas for further innovation with run-levels.
It is difficult to discuss the init program without first having
an understanding of what it controls. The init process is invoked by
the kernel itself and becomes the parent of all other processes on a
machine. At startup, the /etc/inittab file is interpreted by init and
all identified routines are processed. The default runlevel for the
system is maintained within inittab.
You can think of a Linux operating system runlevel as the "application
state" of the machine. For each distinct state, select processes are
functional. Table 3.1 displays the known list of runlevels and their
impact on user access.
TABLE 3.1: RUNLEVELS
Runlevel
Script Directory
Definition
0
rc0.d
System is stopped
S
rc1.d
Single user mode accessed from the boot prompt
1
rc1.d
Single user mode
2
rc2.d
Multiuser mode but no network available
3
rc3.d
Multiuser mode with full network access
4
rc4.d
N/A, an unused runlevel
5
rc5.d
Multiuser network enabled including the X Windows System
6
rc6.d
Forces a machine to reboot
You initiate transitions between states by running the init routine
followed by the runlevel. Each transition, in turn, changes which processes
are running. The application startups or shutdowns triggered by a change
in the runlevel are managed through a series of script files. The directory
/etc/init.d is the base directory for a collection of directories, each
of which, represents a distinct runlevel. Within each level's directory
resides a collection of appropriate scripts for the applications required
for the specific runlevel.
When the system enters a particular state, it initiates all the appropriate
routines for that state by executing all the script files that begin
with the letter S (Start) in the corresponding directory.
Similarly, when the system is leaving a source level for another,
the scripts residing in the source directory beginning with the letter
K (Kill) are processed. This ensures that all applications that are
supposed to run only in a particular level are shut down properly before
the system moves onto the next runlevel.
The one exception is one of efficiency. If a start script for a specific
application exists in the target level, the stop (Kill) script in the
source level is ignored.
As an example, you can examine the change of state from runlevel
3 and runlevel 5 on the xdm application. Xdm is the X Windows System
display manager. Referring to Table 3.1, X is available only at runlevel
5. Listing 3.3 show the files associated with xdm in the /etc/init.d/rc5.d
directory.
From Listing 3.3, it is possible to see that xdm is both started
and stopped as the system enters or leaves runlevel 5. What is also
apparent is that both the startup and shutdown scripts are simply links
to the same script residing in /etc/init.d. This linking minimizes duplication
of the scripts, ensuring a consistent application startup and shutdown
independent of target runlevel.
The init process can therefore be defined as a tool used to control
which applications are active on a system. You can identify which applications
are active within a runlevel by looking at content of the subdirectory
for the level in question.
Linux operating systems utilize runlevels to determine the services
that should be running and to allow specific work to be done on the
system. For example, runlevel one is designated single-user mode without
networking and is used for critical system maintenance and troubleshooting.
Runlevel three is multi-user text mode. Runlevel five is multi-user
graphical mode.
Switching between runlevels is accomplished using the init command.
Entering:
# init 5
will change to runlevel five. Changing to runlevel six will reboot
the machine and runlevel zero will shut down the machine.
Entering runlevel at the command prompt will output the previous
and current runlevels. For example:
#runlevel
N 5
indicates that the machine is in runlevel five. The 'N' indicates
that the machine was booted into level five, or no previous runlevel
was entered.
As mentioned previously, the different runlevels are configured to
run a specific set of services. Each runlevel is configured to start
its specified services when starting and to shut down its services when
switching to a different runlevel.
As a general rule, turn off all services that are not needed at a
given runlevel. Managing the services started in each runlevel is simple
and can be done graphically in YaST or at the command line with the
chkconfig command.
Managing Runlevel Services With YaST
YaST offers a robust and easy to use runlevel service configuration
tool. Access the tool at YaST > System > Runlevel Editor. Within the
tool, turn services on or off by selecting the service and then selecting
the Enable/Disable buttons.
Selecting expert mode allows the administrator to configure the state
of a service in each runlevel.
For example, use the YaST runlevel editor to configure the OpenSLP
daemon, slpd, to start in runlevels three and five only. Do the following:
Select YaST > System > Runlevel Editor.
Select the Expert Mode radio button.
In the services list, select slpd.
Use the check boxes to select runlevels three and five. Deselect
all other runlevels.
Save changes and exit.
Managing Runlevel Services With chkconfig
Most Linux distributions include the chkconfig command for managing
runlevel services. The syntax for chkconfig is specified in the chkconfig
man page.
For example, use chkconfig to configure the OpenSLP daemon, slpd,
to start in runlevels three and five only. Do the following:
Unlike most non-UNIX operating systems which only have 2 modes of
functionality (on and off), UNIX operating systems, including Linux,
have different runlevels such as "maintenance" runlevel or "multi-user"
runlevel, etc.
Runlevels are numbered from 0 to 6 and will vary from one Linux distribution
to another. The description for each runlevel functionality is sometimes
documented in /etc/inittab.
Runlevel
Purpose
0
Shuts down the machine safely. The operating system will
also attempt to poweroff the system if possible
1
Single user mode. Only one terminal is available for the
(single) user root. All other users are logged
out
Like runlevel 3 but runs a Display Manager as well
6
restarts the machine safely
[a]
These runlevels may vary in functionality between Linux
flavours. But these descriptions correspond to the current LSB
specification.
2.2.1. INIT Controls Runlevels
Both init and telinit are used
to switch from one runlevel to another. Remember that init
is the first program launched after the kernel has accessed the root
device.
At boot time init is instructed which runlevel to reach in
/etc/inittab with the line:
id:5:initdefault:
When the system is started it is possible to change runlevels by
invoking init (or telinit which is
a symbolic link pointing at init).
For example we switch to runlevel 4 with either of the next commands:
init 4
telinit 4
The PID for init is always 1. It is possible to
find out which runlevel the system is currently in with the command
runlevel
runlevel
N 5
The first number is the previous runlevel (or N if not applicable)
and the second number is the current runlevel.
The Last but not LeastTechnology 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
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
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.
TrevorH
that I want to see and I can't slam the Scroll Lock fast enough to catch it. Anyone know how to get the details to scroll up rather than the blank and re-write?
