LINUX-24
SERVICE MANAGEMENT FRAMEWORK (RHEL-7)
SYSTEMD/SYSTEMCTL – PART-1
Systemd: system
management daemon
First process while booting RHEl-7 is “systemd”. In RHEL-7 the legacy
“init” daemon and the “upstart” process is replaced by “systemd”.
Systemd makes the boot faster by starting services in parallel by
keeping track of all dependencies between units and only those services are
started which are strictly required at boot, rest services are started on
demand.
First it was “init” then “upstart” and now it is “systemd”.
INIT/SYSVINIT: (RHEL-5 &
Before)
Init is the parent of all processes. Its primary role is to create
processes from a script stored in the file /etc/inittab. This instructs init to
read an initial configuration script for the environment, which sets the path,
starts swapping, checks the file systems, and so on.
Then init continues to read the /etc/inittab file, which describes
how the system should be set up in each run level and sets the default run
level.
The file also specifies which services and daemons are available in
each of the runlevels. Depending on the entries in /etc/inittab, several
scripts are run by init. These scripts, called init scripts, all reside in the
directory /etc/init.d
Init is the process with process ID 1.
Booting with init was based on runlevel directories that contained N
number of scripts that all had to be started, whether they are required now or
not.
The entire process of starting the system and shutting it down is
maintained by init.
“A runlevel is a software configuration of the system which allows
only a selected group of processes to exist.”
/etc/inittab at RHEL-5 (Several uncommented entries) èè
INIT/SYSVINIT
[root@rhel5-server ~]# grep -v "#" /etc/inittab
id:3:initdefault:
si::sysinit:/etc/rc.d/rc.sysinit
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System
Shutting Down"
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown
Cancelled"
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
x:5:respawn:/etc/X11/prefdm -nodaemon
co:2345:respawn:/sbin/agetty -L ttyS0 115200 vt100-nav
Look, how rich the RHEL-5 is with uncommented “inittab” entries JJ…
[root@rhel5-server ~]# ls -ld /etc/rc*
lrwxrwxrwx 1 root root
7 Jan 18 2012 /etc/rc ->
rc.d/rc
drwxr-xr-x 10 root
root 4096 Feb 15 2012 /etc/rc.d
lrwxrwxrwx 1 root root
13 Jan 18 2012 /etc/rc.local
-> rc.d/rc.local
lrwxrwxrwx 1 root root
15 Jan 18 2012 /etc/rc.sysinit
-> rc.d/rc.sysinit
lrwxrwxrwx 1 root root
10 Jan 18 2012 /etc/rc0.d ->
rc.d/rc0.d
lrwxrwxrwx 1 root root
10 Jan 18 2012 /etc/rc1.d ->
rc.d/rc1.d
lrwxrwxrwx 1 root root
10 Jan 18 2012 /etc/rc2.d ->
rc.d/rc2.d
lrwxrwxrwx 1 root root
10 Jan 18 2012 /etc/rc3.d ->
rc.d/rc3.d
lrwxrwxrwx 1 root root
10 Jan 18 2012 /etc/rc4.d ->
rc.d/rc4.d
lrwxrwxrwx 1 root root
10 Jan 18 2012 /etc/rc5.d ->
rc.d/rc5.d
lrwxrwxrwx 1 root root
10 Jan 18 2012 /etc/rc6.d ->
rc.d/rc6.d
More details can be found at,
/etc/inittab at RHEL-6 (only one uncommented entry) èè
UPSTART
[root@rhel6-server ~]# grep -v "#" /etc/inittab
id:5:initdefault:
[root@rhel6-server ~]# ls -ld /etc/rc*
lrwxrwxrwx. 1 root root
7 Aug 30 03:44 /etc/rc -> rc.d/rc
lrwxrwxrwx. 1 root root
10 Aug 30 03:44 /etc/rc0.d -> rc.d/rc0.d
lrwxrwxrwx. 1 root root
10 Aug 30 03:44 /etc/rc1.d -> rc.d/rc1.d
lrwxrwxrwx. 1 root root
10 Aug 30 03:44 /etc/rc2.d -> rc.d/rc2.d
lrwxrwxrwx. 1 root root
10 Aug 30 03:44 /etc/rc3.d -> rc.d/rc3.d
lrwxrwxrwx. 1 root root
10 Aug 30 03:44 /etc/rc4.d -> rc.d/rc4.d
lrwxrwxrwx. 1 root root
10 Aug 30 03:44 /etc/rc5.d -> rc.d/rc5.d
lrwxrwxrwx. 1 root root
10 Aug 30 03:44 /etc/rc6.d -> rc.d/rc6.d
drwxr-xr-x. 10 root
root 4096 Aug 29 22:28 /etc/rc.d
lrwxrwxrwx. 1 root root
13 Aug 30 03:44 /etc/rc.local -> rc.d/rc.local
lrwxrwxrwx. 1 root root
15 Aug 30 03:44 /etc/rc.sysinit -> rc.d/rc.sysinit
[root@rhel6-server ~]# ls -ld /etc/init.d
lrwxrwxrwx. 1 root root 11 Aug 30 03:41 /etc/init.d -> rc.d/init.d
/etc/inittab at RHEL-7 (no uncommented entry) è è
SYSTEMD
[root@rhel7-client ~]# grep -v "#" /etc/inittab
[root@rhel7-client ~]#
[root@rhel7-client ~]# ls -ld /etc/rc*
lrwxrwxrwx. 1 root root
10 Oct 22 12:27 /etc/rc0.d -> rc.d/rc0.d
lrwxrwxrwx. 1 root root
10 Oct 22 12:27 /etc/rc1.d -> rc.d/rc1.d
lrwxrwxrwx. 1 root root
10 Oct 22 12:27 /etc/rc2.d -> rc.d/rc2.d
lrwxrwxrwx. 1 root root
10 Oct 22 12:27 /etc/rc3.d -> rc.d/rc3.d
lrwxrwxrwx. 1 root root
10 Oct 22 12:27 /etc/rc4.d -> rc.d/rc4.d
lrwxrwxrwx. 1 root root
10 Oct 22 12:27 /etc/rc5.d -> rc.d/rc5.d
lrwxrwxrwx. 1 root root
10 Oct 22 12:27 /etc/rc6.d -> rc.d/rc6.d
drwxr-xr-x. 10 root
root 4096 Apr 8 2014 /etc/rc.d
lrwxrwxrwx. 1 root root
13 Oct 22 12:30 /etc/rc.local -> rc.d/rc.local
[root@rhel7-client ~]# ls -ld /etc/init.d
lrwxrwxrwx. 1 root root 11 Oct 22 12:27 /etc/init.d -> rc.d/init.d
We will learn about “init” and its functions in some later post.
UPSTART: (RHEL-6)
When we had “init” then why “upstart” introduced…?
Easiest example in my mind is of a Restaurant.
Case-1:
We are sitting at a restaurant and they feed us all whatever in their
breakfast menu, regardless we want it or not, even the restaurant doesn’t care
if catering of breakfast continues till lunch. All of their staff busy with us
until we finish. One more thing to consider, they are feeding us as per their
menu order, if sandwich is at 1st place and cheese sandwich is at 2nd
place and omelet is at 3rd place then they will feed us in same
order till they reach the last one.
JJ
Case-2:
We are sitting at a restaurant and they are waiting for our
instructions to serve, whatever & whenever we want.
Which one is better…?
THE EVENT DRIVEN INITIALIZATION…………………….. Is UPSTART.
What does “Event Driven” stands for…?
Init follows a sequential process, each tasks load in a predefined
sequence as the system boots. Init is concerned with the sequence only when we
are booting up or powering down.
Whereas Upstart is an event-driven init daemon, it will only start a
service if there is an external event requiring it.
It has the benefit that maximum part of the service configuration is
handled automatically and since only necessary services will run, resulting
faster startup times and less resource consumption.
In RHEL-6 init has been replaced with Upstart, an event-driven init
system.
This system handles the starting of tasks and services during boot,
stopping them during shutdown and the most important is to supervising them
while the system is running.
Processes are known to Upstart as jobs and are defined by files in
the /etc/init directory.
FROM WIKIPEDIA ABOUT UPSTART,
The traditional init process was originally only responsible for
bringing the computer into a normal running state after power-on, or gracefully
shutting down services prior to shut down. As a result, the design is strictly
synchronous,
blocking future tasks until the current one has completed. Its tasks
must also be defined in advance, as they are limited to this prep or cleanup
function. This leaves it unable to handle various non-startup-tasks on a modern
desktop computer elegantly, including:
·
The
addition or removal of USB flash drives and other portable storage or
network devices while the machine is running
·
The
discovery and scanning of new storage devices, without locking
the system, especially when a disk may not even power on
until it is scanned
·
The
loading of firmware for a device, which may need to occur after
it is detected but before it is usable
Upstart's event-driven model allows it to respond to events asynchronously
as they are generated.
Design:
Upstart operates asynchronously; it handles starting of the tasks and
services during boot and stopping them during shutdown, and also supervises the
tasks and services while the system is running.
Easy transition and perfect backward compatibility with sysvinit were
the explicit design goals; accordingly, Upstart can run unmodified sysvinit
scripts. In this way it differs from most other init replacements (beside
systemd and OpenRC), which usually assume and require complete transition to
run properly, and do not support a mixed environment of traditional and new
startup methods.
Upstart allows for extensions to its event model through the use of
initctl to input custom, single events, or event bridges to integrate many or
more complicated events. By default, Upstart includes bridges for socket, dbus,
udev, file, and dconf events; additionally, more bridges are possible.
For more info, please visit
SYSTEMD: (RHEL-7)
We walked through Sequential execution, Event-Driven
execution and now the time is for PARALLEL Execution.
·
Systemd is a system daemon and service manager for
Linux
operating systems.
·
Designed to be backwards compatible with SysV init
scripts
·
Parallel startup of system services results in
faster boot time
·
On-demand activation of daemons
·
Support for system state snapshots
·
Automatic dependency handling to avoid longer time
outs.
·
Monitoring of started services with the ability to
restart
crashed services.
There is no more /etc/inittab. Instead we have
/etc/systemd/system & /usr/lib/systemd/system
During the boot process Linux (RHEL_7) loads the “temp fs” in to RAM,
then HW drivers are loaded and then first process is started “systemd”.
In RHEL-7 the legacy “init” process is configured with a sym link to “systemd”.
Next, systemd activates all the system units for “initrd.target” and
mounts the root FS under /sysroot. Finally systemd restarts itself in the new
root directory and activates all units for the default targets.
Here two new things came in picture,
1. Unit
2. Target
So what is “unit” & “target”…??
Everything in UNIX is “file”. In same manner, from the perspective of
systemd “Everything is UNIT”.
Units are the basic building blocks of systemd.
Systemd is used to start “some-things”, these some-things later
represent “too many-things”.
These some-things are called UNITS.
System is meant to perform in certain fashion, this fashion must need
certain order to be followed, and these orders must require certain
functionality to be obeyed.
Here come the “unit” files. UNIT's are used to build the functionality
which is required by system to work in correct manner/order.
Hence the systemd loads them in correct order at correct moment.
There are some special types of “units” called “TARGET UNITS”.
Simply a group of certain units are called “target units”.
CONTINUED............
No comments:
Post a Comment