Init
System V Init daemon is the first process (pid=1) to start on linux and continues running until the system shuts down. It is the eventual parent of any process you start on linux.
System V was the first commercial Unix OS.
The primary function of init daemon is to launch the userspace, in other words, initialise the processes for linux startup by reading the information from the /etc/inittab file.
The file defines 3 important items for init process -
1. system's default run level
2. what processes to start, monitor and restart if they terminate
3. what actions to take when the system enters a new run level
each entry in the /etc/inittab has following fields -
id:rstate:action:process
id - unique identifier of entry
rstate - list of run levels to which this entry applies. eg. 1 or 13 or 234
action - how the process is to be run. possible values - initdefault, sysinit,
Once initd does it's job on initialising the userspace, add-on service managers like service and chkconfig are used to make the service management easier.
init diligently serves the master but is constrained in that it starts the processes serially, performs dependency checks on each one and waits for daemons to start so more daemons can start and so on, which leads to a slower than can be boot time.
The (not so) new kiddo on the block. Aims to solve the problem with initd by starting daemons in parallel. How ?
Takes advantage of how unix-type daemons work. The clients of unox daemons don't need to know if the daemons they depend on are actually running, but only if the correct respective Unix Domain Sockets are available.
So, all sockets for all daemons are created in one step and then the daemons themselves are created in the next step.
Any client requests for daemons that are not yet running are cached in the socket buffer and the filled up when the daemon is running.
Now we have
which contains the init scripts.
To start a service at boot, it must be linked to /etc/systemd/system. systemctl command does this when a new service is enabled.
# systemctl enable <service>
The init scripts are provided by vendors for the applications. Many vendors such as Apache have not caught up to systemd and don't have systemd init scripts. Some vendors provide bot the systemd as well as sysvinitd init scripts.
The init scripts contains information about
- where to create the symlink
- any dependencies
There are 3 possible states - enabled | disabled | static
None of these states tells whether service is running or not.
To check the status of service -
# systemctl start [name.service]
# systemctl stop [name.service]
# systemctl restart [name.service]
# systemctl reload [name.service]
$ systemctl status [name.service]
# systemctl is-active [name.service]
$ systemctl list-units --type service --all
$ systemd-analyze blame
https://en.wikipedia.org/wiki/Unix_domain_socket
https://www.linux.com/tutorials/understanding-and-using-systemd/
System V Init daemon is the first process (pid=1) to start on linux and continues running until the system shuts down. It is the eventual parent of any process you start on linux.
System V was the first commercial Unix OS.
The primary function of init daemon is to launch the userspace, in other words, initialise the processes for linux startup by reading the information from the /etc/inittab file.
The file defines 3 important items for init process -
1. system's default run level
2. what processes to start, monitor and restart if they terminate
3. what actions to take when the system enters a new run level
each entry in the /etc/inittab has following fields -
id:rstate:action:process
id - unique identifier of entry
rstate - list of run levels to which this entry applies. eg. 1 or 13 or 234
action - how the process is to be run. possible values - initdefault, sysinit,
boot, boot wait, wait, respawn
process - command/script to run
Run Levels -
0 - Power Down State
1 - Single User State
2 - Local Multiuser without remote network (eg NFS)
3 - Full multiuser with network
4 - Not used
5 - Full multiuser with network and GUI
6 - System reboot
To check current run level -
who -r
Once initd does it's job on initialising the userspace, add-on service managers like service and chkconfig are used to make the service management easier.
init diligently serves the master but is constrained in that it starts the processes serially, performs dependency checks on each one and waits for daemons to start so more daemons can start and so on, which leads to a slower than can be boot time.
Unix Domain Sockets
Unix Domain Socket is a communication endpoint for exchanging data between processes executing on the same host OS. Valid socket types on Unix are - SOCK_STREAM (kinda TCP), SOCK_DGRAM (kinda UDP) and SOCK_SEQPACKET (kinda SCTP).
API of Unix Domain sockets is similar to that of Internet socket, but rather than using underlying network protocol, all communication happens inside OS kernel. Processes reference sockets as FS inodes, so two processes can communicate by opening the same socket.
$ netstat -a --protocol=unix
SystemD (...similar movement k/a upstart in Ubuntu, toppled by systemd in ubuntu 14.10)
UID PID PPID CMD
root 1 0 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
Takes advantage of how unix-type daemons work. The clients of unox daemons don't need to know if the daemons they depend on are actually running, but only if the correct respective Unix Domain Sockets are available.
So, all sockets for all daemons are created in one step and then the daemons themselves are created in the next step.
Any client requests for daemons that are not yet running are cached in the socket buffer and the filled up when the daemon is running.
Now we have
/etc/systemd/system
directory which contains symlinks to files in
/usr/lib/systemd/system which contains the init scripts.
To start a service at boot, it must be linked to /etc/systemd/system. systemctl command does this when a new service is enabled.
# systemctl enable <service>
The init scripts are provided by vendors for the applications. Many vendors such as Apache have not caught up to systemd and don't have systemd init scripts. Some vendors provide bot the systemd as well as sysvinitd init scripts.
The init scripts contains information about
- where to create the symlink
- any dependencies
$ systemctl list-unit-files --type=service <<<< lists states of installed services
None of these states tells whether service is running or not.
To check the status of service -
$ systemctl status auditd.service
# systemctl start [name.service]
# systemctl stop [name.service]
# systemctl restart [name.service]
# systemctl reload [name.service]
$ systemctl status [name.service]
# systemctl is-active [name.service]
$ systemctl list-units --type service --all
$ systemd-analyze blame
https://en.wikipedia.org/wiki/Unix_domain_socket
https://www.linux.com/tutorials/understanding-and-using-systemd/
No comments:
Post a Comment