Process Manager-{systemd}
Earlier, The only thing I knew about systemd is like it is the first process that starts on the system by the kernel, hence it is a child to no other process. It has been like mystifying to me, it was so because i could not get how it actually works, then I tried out reading manuals, and article on systemd but none of them made that clear, until i came aroross these two articles first, second and the book on Orielly(how Linux works).
Before we begin, lets see some of the prerequisite for starting with the systems,
Firstly I would love to give you all just the gist on how the system boots up so, once the power button is hit, then BIOS or UEFI which is the firmware what this will do is like performs a self-test and initializes the hardware, now firmware ie BIOS looks for the bootable device(bootLoader) on hard disk, once the bootable device is encountered and loaded, then at this point control is passed from the BIOS to bootLoader, then what this bootLoader will start the GRUB CLI also called grub menu, its job is to load the kernel on the ram (memory) and the file system(“”initramfs”” with context to RHEL 8) ie here kernel set up rootdisk, with the help of which kernel starts on ram, now once the kernel starts, the OS will need the primary filesystem and kernel with the help of systemd sets of primary FileSystem is /sysroot (this is the final filesystem for root ie mounted on)
so here on systemd is set up and is initialized, we will be dealing with the Unit files, these are the places where systemd looks for system unit files in this order:
- “/etc/systemd/system” #administrator needs to make use of this places
- “/run/systemd/system”
- “/usr/lib/systemd/system” #which is used by the OS distribution(system)
Now talking about types of unit files, there are total of seven types of unit files used by the systems
SONU@HOST>>>>>systemctl -t help
Available unit types:
service
socket
busname
target
snapshot
device
mount
automount
swap
timer
path
slice
Scope
SONU@HOST>>>>>systemctl -t help |wc -l
14Unit files are all structured like this.
below is the service unit file for nginx container .
#EXAMPLE UNIT FILE(THIS FILE IS FOR PODMAN CONTAINER(NGINX) SERVICE)
[Unit]#THIS IS THE UNIT SECTION
Description=Podman container-f4e1c6787212ac9eaa0d5e12c22234fae775fb7ec54c32b2e2d45ecf9d6af081.service
Documentation=man:podman-generate-systemd(1)[Service]
Restart=on-failure #THESE ARE THE KEY PAIR DIRECTIVES
ExecStart=/usr/bin/podman start f4e1c6787212ac9eaa0d5e12c22234fae775fb7ec54c32b2e2d45ecf9d6af081
ExecStop=/usr/bin/podman stop -t 10 f4e1c6787212ac9eaa0d5e12c22234fae775fb7ec54c32b2e2d45ecf9d6af081
KillMode=none
Type=forking
PIDFile=/var/run/containers/storage/overlay-containers/f4e1c6787212ac9eaa0d5e12c22234fae775fb7ec54c32b2e2d45ecf9d6af081/userdata/conmon.pid[Install]
WantedBy=multi-user.target
They contain sections (like [Unit]) and key-value pairs, called directives. You can learn more about which directives exist for each unit type in the man pages (for example, man systemd.service for services, or man systemd.unit for directives available for all units; use man systemd.directives if you have a directive and want to know in which man page it is defined).
Types of unit files and its description
According to me the most used unit files (from mine point of view)amongst the above list are
a)target
b)service
c)socket
Now, from the above three lists, what i feel is target files are a bit useless, so what makes it useful is the dependencies which are like fundamental to systemd(note:- dependencies is what makes the systemd better than system v init which was nothing but the scripts for starting to init process )and because of the dependencies the service unit file came in picture which in actual perform all the major jobs/work ,hence service are nothing but the process controlled by the systemd(process manager)
Where as socket, Socket units have a .socket extension and represent inter-process communication (IPC) sockets that systemd should monitor. If a client connects to the socket, systemd will start a daemon and pass the connection to it. Socket units are used to delay the start of a service at boot time and to start less frequently used services on demand.
So, by above para what I can conclude is like , service unit file is the one that what to do/is to be done whereas the dependencies in the target file tells when to do. And socket are the one that opens up , like opens endpoint for the user.
Different States of unit:-
there are namely 5 states of unit file:-
- active
- activating
- deactivating
- inactive and
- failed
so, by default all the unit files are inactive state, once the unit files are triggered implicitly or explicitly they change their state to activating and then to active, and once they encounter kill/stop signal they change their state to deactivating and will finally will be in active state. And in the process if some error is encountered the state will be in failed status.
DEPENDENCIES
As discussed above ,Dependcies are the one that is fundamental to the systemd and makes it standout wrt to system v init. Now taking a closer look at dependencies, they can be classified into two types :
- Ordering:-these dependencies are like the strict rule to followed, as its name suggest “order”.
- Requirment:- here, if these dependencies are used, they can use to trigger at once(here i mean they can be used to trigger many unit in parallel), and as its name suggest “require” its saying that it its totally dependent on the pointing unit file.
1. order Dependencies:-(before,after)
- suppose, we have unit file1 and unit file2 , and unit file1 has this directive“After=unit file2” then once the unit file1 is triggered to be activate, it will first ensure that unit file2 is successfully activated then only the unit file1 will change its state to activating and will finally activate.
- If unit file1 has this directive Before=unit file2, then unit file1 will change its state to activated before unit file2 is triggered to activate state.
2. requirement Dependencies:-(wants,require)
- now If unit file1 has Wants=unit file2 then unit file1 will just trigger the unit file2 to activate and unit file1 will not be concern at all about unit file2 is successfully activated or failed.unit file1 will just start after triggering the unit file2.
- In case of Require , you can consider same as After (ie order dependencies), so the difference is like if the RHS of Require is stopped explicitly then the unit with the Require is also stopped(here we can think of multi-user.target and graphical.target refer the following example and focus on the “require” directive, suppose if we close the multi-user.target then graphical.target will stop on its own)
[root@SONU system]# cat graphical.target
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes