| |
CentOS system startup process:
POST -> Boot Sequence -> Bootloader -> kernel + initramfs (initrd) -> rootfs -> / sbin / init
innit program:
CentOS 5: SysV init
CetnOS 6: Upstart
CentOS 7: Systemd
Systemd new features:
Sys V init system and LSB init scripts compatible
Implementation of the service when the system boots started in parallel; using socket / D-Bus activation technology start the service; To reduce boot time, systemd goal is: as far as possible to start the process less; as more processes started in parallel;
Demand activation process; Systemd can provide the ability to start on demand, only when a service is requested before the real start it. When the end of the service, systemd can turn it off, wait for the next time you need to start it again.
The system can snapshot and recovery;
Start mount points, and automatic mount point management:
Systemd mount point on the self-management system, so that they can be mounted automatically at system startup. And is compatible / etc / fstab file;
Implement transaction dependency management:
systemd maintains a "transaction consistency" concept, to ensure that all relevant services can be started normally and will not appear depend on each other, so that a deadlock situation.
Endogenous dependencies defined service control logic;
system use the Linux kernel feature that is CGroup to complete the process of tracking tasks. When you stop the service by querying CGroup, systemd can be found to ensure that all relevant processes, so as to cleanly stop the service;
Log service: systemd comes log service journald, designed the log service is to overcome the disadvantages of existing syslog service.
Basic Concepts of System
The concept of unit:
System initialization needs to be done very much. Need to start background service, such as start SSHD service; configuration work needs to be done, for example, mount the file system. Each step in this process are systemd abstracted as a hive that unit. It can be considered a service is a hive; a mount point is a hive; a swap partition configuration is a hive; and so on. systemd hive summarized in the following few different types. However, systemd is evolving rapidly increasing new features. So the type of hive may continue to increase in the near future.
- service: the representative of a background server process, such as mysqld. This is a common type;
- socket: this type of hive packaging system and the Internet in a socket. Moment, systemd support streaming, packet and package of continuous AF_INET, AF_INET6, AF_UNIX socket. Each unit has a socket configuration corresponding service hive. The appropriate service when the first "connected" to enter the socket starts (for example: nscd.socket in new connections after the start nscd.service).
- device: such a package exists in the hive Linux devices in the device tree. Each device uses udev rules are labeled in systemd will hive as a device appears.
- mount: this type of package hive file system hierarchy in a mount point. Systemd mount point will be monitored and managed. For example, it can automatically mount at boot; can automatically unloaded under certain conditions. Systemd will / etc / fstab entries are converted to the mount point, and processed at boot time.
- automount: such a hive in the packaging system hierarchy from a mount point. Each unit corresponds to a self-mount configuration mount hive, when the automatic mount point is accessed, systemd perform a mount point defined mount behavior.
- swap: hive and mount similar exchange hive used to manage swap. Users can configure the switching unit to define the system swap partition, you can make these swap at startup is activated.
- target: Such hive logical grouping for other hive. They themselves do not actually do anything, but just refer to other hives. This makes it possible to configure the unit to make a unified control. This allows running a conceptual level we are already very familiar with. For example, want the system to enter the graphical mode, you need to run many services and configuration commands, these operations are controlled by one of the hive, he said a combination of all these hives as a goal (target), it means that you need to perform all of these hives again in order to enter the target represents the system running. (Example: multi-user.target equivalent to running traditional use SysV system Level 3)
- timer: Timer hive used to periodically trigger user-defined actions, such hive replaced atd, crond traditional timing services.
- snapshot: similar to the target hive, the hive is a group of the snapshot. It saves the current state of the system.
Dependencies:
Although a lot of systemd will start work to lift the dependency so that they can be complicated to start. But there is still some tasks, dependencies exist between them naturally, can not use a "socket activation" (socket activation), D-Bus activation and autofs three ways to wean (the three methods detailed in the subsequent description). For example: mount must wait for the mount point is created in the file system; mount also must wait for the corresponding physical device is ready. In order to solve these dependencies, between systemd hive can define codependent relationship.
Systemd with hive definition file keywords to describe the dependencies between the hive. For example: unit A dependency unit B, can "require A" to indicate the definition of unit B is used in. Such systemd will ensure first start A restart B.
Systemd transaction:
Systemd to ensure transaction integrity. Systemd transactional database concepts and different, mainly in order to ensure that no endless references between multiple dependent hive. Circular dependency, the systemd will not start any of the services. At this point systemd will try to solve this problem, because the dependencies between the hive, there are two: required is a strong dependence; want is a weak dependence, systemd will remove wants keyword specified see if we can break the cycle of dependency. If you can not repair, systemd error.
Systemd can automatically detect and repair this type of configuration errors, greatly reducing the burden on administrators troubleshooting.
Target and run level:
systemd in the target (target) instead of the concept of run levels, providing greater flexibility, as you can inherit an existing target and add other services to create their own goals. The following table lists the correspondence between the target and under the common runlevel systemd
Systemd principle of simultaneous start
As described above, in Systemd, all services are started concurrently, such as Avahi, D-Bus, livirtd, X11, HAL can be started simultaneously. At first glance, this seems a little problem, such as Avahi need syslog service, Avahi and syslog started simultaneously, assuming Avahi start faster, so syslog was not ready, but they need Avahi logging, this would not be a problem ?
Systemd developers carefully study the nature of the problem of interdependence between the service and found that the so-called dependency can be divided into three specific types, and each type can actually relieve dependence through appropriate technology.
- Concurrent start one principle: to solve the socket dependence
The vast majority of service depends on the socket is dependent. A service such as providing their services through a socket port S1, other services if needed service A, you need to connect S1. So if A service has not been started, S1 does not exist, other services will get startup errors. So Traditionally, people need to start service A, wait for it to enter the ready state, and then start the other services that require it. Systemd that as long as we advance the S1 is set up, then all the other services can be started simultaneously without waiting for a service A to create S1. A If the service is not started, then the service request process actually sent to S1 will be Linux operating system cache will wait for other processes where this request. A Once the service is ready to start, you can process the request cache immediately, everything begins normal operation.
So how to use the service sockets created by the init process it?
Linux operating system has a feature that, when the process calls fork or exec create a child process, the parent process is all open file handle (file descriptor) are inherited by child processes. Socket is a file handle, process A can create a socket, then when process A calls exec to start a new child process, just make sure the socket close_on_exec flag is cleared, then the new child process you can inherit the socket. Sockets sockets and the parent process child process created a system see the same socket, the socket is the same as if the child process to create their own, without any distinction.
This feature was previously used by a system called the inetd service. Inetd process will be responsible for monitoring some common socket port, such as Telnet, when there is a connection request on the port, inetd starts telnetd process only, and to have a socket connection is passed to the new telnetd process to be processed. Thus, when the system does not telnet client connections, you need to start telnetd process. Inetd can represent a lot of network services, so you can save a lot of system load and memory resources only when there is a real connection request to start the appropriate services, and the socket is passed to the service process.
And similar inetd, systemd is the parent of all other processes, it may be required to establish all the sockets, and then calling exec when the socket is passed to the new service process, and the new process directly using the socket word the service.
- Concurrent start of the two principles: to solve the D-Bus dependence
D-Bus is a desktop-bus for short, it is a low-latency, low overhead, between the high-availability process communication mechanism. It is increasingly being used for communication between applications, but also for communication applications and the operating system kernel. Many modern service processes use D-Bus interprocess communication as substituted socket mechanism, external services. Such as simplified Linux network configuration NetworkManager service is using D-Bus to interact with other applications or services: e-mail client software evolution can obtain network status change from NetworkManager service via D-Bus, in order to make the appropriate treatment.
D-Bus supports so-called "busactivation" function. Auto-start service if the service requires the use of service B A D-Bus service for a B and is not running, you can request D-Bus service B D-Bus service A B. The service request will be issued A D-Bus cache waits for service A service B ready to start. With this special, dependent D-Bus services can be achieved in parallel to start.
Three concurrent start of principle: to resolve the file system dependent
During system startup, the file system-related activities is the most time-consuming, for example, mount the file system, the file system disk check (fsck), disk quotas inspections are very time-consuming operation. Waiting for this has been done at the same time, the system is idle. Those who want to use the file system service appears to have to wait for the file system initialization is complete before you can start. But systemd found that this dependence is avoided.
Systemd reference autofs design ideas, so that both initialize itself can be complicated jobs depend file system services and file systems. autofs can monitor a file system mount point actually be accessed when it is triggered to mount the operation, which is supported by the kernel automounter module achieved. For example, a open () system call to action "/ misc / cd / file1" when, / misc / cd mount operation has not been performed, then open () call is pending wait, Linux kernel notification autofs, autofs mount execution . At this time, control is returned to the open () system call, and normally open the file.
Systemd integrated autofs implementations, the system mount points, such as / home, when the system starts, systemd automatically create a temporary mount point. At this moment / home mount the device is not really a good start, really mount operation has not been performed, the system detects the file has not yet completed. But those who depend on the process can be complicated directory already started their open () operation is built in systemd in autofs capture, the open () call to suspend (interruptible sleep state). And then wait for the real mount operation is completed, the file system detects also completed, systemd replace the automatic mount point for the real mount point, and let the open () call returns. Thus, to achieve that rely on the file system services and file system itself simultaneous start.
Of course, for "/" is actually dependent on the root directory or to a certain serial execution, since systemd themselves stored in / under, you must wait for the system to check the root directory is mounted good.
But the case for similar / home mount point, etc., which can improve the startup speed of concurrent systems, especially when / home is an NFS remote node, or encrypted disk, etc., it takes a long time to be ready by the because concurrent start, this time, the system is not entirely nothing to do, but you can use this spare time to do something more to start the process, in general shortens the system startup time.
Systemd use
The following role-technical staff to brief you use systemd. This article is only intended to give a simple description that allows you to use systemd have a general understanding. Specific details of too much, it can not be written in full in an essay. Also you need the reader to further consult systemd documents.
Unit prepared documents
Developers have developed a new service program, such as httpd, you need to prepare for a hive file so that the service can be managed systemd, UpStart similar work profile. Service startup command line syntax definitions, as well as other services and dependencies, etc. in the file.
In addition, we have previously learned, systemd's many functions, not only to manage the service, you can also manage mount points, the definition of regular tasks. These are done by editing the appropriate configuration file to complete the unit. I am here to give a few examples of the hive file.
Here is the hive file SSH service, service .service hive file to the file name suffix.
[Root @ kalaguiyin system] # cat / usr / lib / systemd / system / sshd.service
[Unit]
Description = OpenSSH server daemon
After = network.target sshd-keygen.service
Wants = sshd-keygen.service
# [Unit] section description
[Service]
EnvironmentFile = / etc / sysconfig / sshd
ExecStart = / usr / sbin / sshd -D $ OPTIONS
ExecReload = / bin / kill -HUP $ MAINPID
KillMode = process
Restart = on-failure
RestartSec = 42s
# [Service] is defined, ExecStartPre custom command before you start the service should be running;
#ExecStart Define specific command-line syntax to start the service.
[Install]
WantedBy = multi-user.target
# [Install] section: WangtedBy indicates that the service is in multi-user mode required.
Then we look at multi-user.target it:
[Root @ kalaguiyin system] # catmulti-user.target
[Unit]
Description = Multi-User System
Documentation = man: systemd.special (7)
Requires = basic.target
Conflicts = rescue.service rescue.target
After = basic.target rescue.servicerescue.target
AllowIsolate = yes
# Requires definition shows multi-user.target start time basic.target must also be started; Also when basic.target stop # waiting, multi-user.target must also stop. If you then view basic.target file, you will find it and other specified sysinit.target # other units must be launched subsequently. Similarly sysinit.target also contain other elements. With this link-layer structure, there is a need to support ultimately the # multi-user mode service components are initialized good start.
[Install]
Alias = default.target
# Alias definitions that define an alias for this unit, so that when the running systemctl can use this alias to refer to this unit.
Also in / etc / systemd / system directory can also be seen, such as * .wants directory on the hive file in that directory is equivalent to [Unit] subsection wants keyword, that this unit starts, also these units need to start. For example, you can simply write your own foo.service under multi-user.target.wants file into the directory, so that each will be activated by default.
[Root @ kalaguiyin system] # pwd
/ Etc / systemd / system
[Root @ kalaguiyin system] # ls
basic.target.wants display-manager.service
bluetooth.target.wants getty.target.wants
dbus-org.bluez.service graphical.target.wants
printer.target.wants sockets.target.wants
spice-vdagentd.target.wants default.target sysinit.target.wants default.target.wants
Let us look at sys-kernel-debug.mout file that defines a mount point file:
[Root @ kalaguiyin system] # cat
sys-kernel-debug.mount
[Unit]
Description = Debug File System
Documentation = https: //www.kernel.org/doc/Documentation/filesystems/debugfs.txt
Documentation = http: //www.freedesktop.org/wiki/Software/systemd/APIFileSystems
DefaultDependencies = no
ConditionPathExists = / sys / kernel / debug
Before = sysinit.target
[Mount]
What = debugfs
Where = / sys / kernel / debug
Type = debugfs
This hive file defines a mount point. Mount hive file has a [Mount] configuration section, which is configured with What, Where, and Type three data items. This is necessary for the mount command, the example configuration is equivalent to the following mount command:
mount -t debugfs / sys / kernel / debug debugfs
Systemd System Management:
The main command-line tool systemd is systemctl.
Most administrators should have been very familiar with the system management services and init systems, such as service, chkconfig and using telinit command. systemd also perform the same management tasks, but the syntax command tool systemctl somewhat different.
1. Start service
systemctl start httpd.service
1. Stop Service
systemctl stop httpd.service
1. Restart Service
systemctl restarthttpd.service
1. Overload Services
systemctl reloadhttpd.service
1. Conditions restarted
systemctl condrestarthttpd.service
1. Status Check
systemctl statushttpd.service
1. List can start or stop a list of services.
systemctl list-unit-files -type = service
1. Set the service to boot
chkconfig httpd on
systemctl enablehttpd.service
1. Cancel the service start-up;
systemctl disablehttpd.service
1. Check for a service in the current environment is configured to enable or disable.
systemctl is-enabledhttpd.service; echo $?
1. Enabling and disabling the output at each level of service is running
systemctl list-unit-files -type = service
1. List to enable and disable a service in which operating level.
ls /etc/lib/systemd/system/*.wants/httpd.service
1. Change the user run levels:
systemctl isolatemulti-user.target
multi-user.target == run level 3
graphical.target == run level 5
runlevel3.target symbolic link multi-user.target
runlevel5.target symbolic link graphical.target
1. Change the default runlevel:
[Root @ kalaguiyinsystem] # systemctl set-default multi-user.target
rm '/ etc / systemd / system / default.target'
ln -s '/ usr / lib / systemd / system / multi-user.target' '/ etc / systemd / system / default.target'
The essence of the operation is to remove /usr/lib/systemd/system/default.target, then the target level of the target file link to /etc/systemd/system/default.target file;
systemd is not just a system of initialization:
systemd is also responsible for the management of other system configurations, such as network configuration, Locale, Management system kernel module is loaded and the like.
Systemd excellent alternative to all the features of sysvinit, but it is not complacent. Because the init process is the parent process systems such particularity of all processes, systemd is excellent for once provided by other services, such as regular tasks (previously done by crond); Session Manager (formerly managed by ConsoleKit / PolKit etc.). Only from the perspective of this article describes the same fur, Systemd pipe was already a lot, it may be evolving. It will gradually become a versatile system environment, able to handle a lot of system administration tasks, and some even see it as an operating system. It is useful for standardized Linux management! |
|
|
|