Systemd detailed in CentOS 7
[Date: 2016-12-01] Source: Linux Community lxlxlx [font: Big Small]
Directory
First, the Origin of SYSTEMD
Second, SYSTEMD
Third, service management
1, SYSTEMCTL2
2. Service View
3. Service Status
4, Hostnamectl
5, Localectl
6, Timedatectl
7, Loginctl
Iv. Unit
1. Unit type
2. Systemctl list-units command to view all the Unit of the current system
3. Unit status
4. Dependency relationship
V. Unit configuration file
1. Overview
2. configuration file Status
3. Configuration file format
1) Unit configuration file format
2) Common options for unit segment
3) Service-common options
4) Install common options
VI. Target
1. Target command
2. The corresponding relationship between target and traditional RunLevel is as follows
3. The main differences between it and the Init process are as follows
Vii. Log Management
1, Journalctl powerful, use very much
2. View the logs of the specified priority (and above) in a total of 8 levels
First, the Origin of SYSTEMD
Linux has always been using the INIT process but Init has two drawbacks:
1, the start time is long. The init process is serial-initiated, and the next process starts only when the previous process starts. (This is also the main feature of CentOS5)
2, the startup script is complex. The init process simply executes the startup script, no matter what else. Scripts need to handle a variety of situations themselves, which makes the scripts very long and complex.
Init:
Centos 5 Sys Init is the slowest startup, serial boot process, regardless of whether the process is dependent on each other.
CENTOS6 upstart Init has improved relatively fast relative to startup speed. There are dependent processes that start in turn and others that do not have dependencies are started in parallel synchronization.
Centos7 Systemd is different from the above. All processes, regardless of dependencies, are started in parallel (although many times the process does not actually start but there is only one signal or token that will actually start when it is actually used.) )
Second, SYSTEMD
Systemd was born to solve the problem above. Its goal is to provide a complete set of solutions for system startup and management. According to Linux conventions, the letter D is an abbreviation for the Daemon (daemon). The meaning of Systemd's name is to protect the whole system.
The Centos 7 SYSTEMD replaces Init, becoming the first process in the system. The PID is 1. All other processes are its child processes. SYSTEMD's advantages are powerful, easy to use, the drawback is the system is huge, very complex. In fact, many people now oppose the use of Systemd, on the grounds that it is too complex to be strongly coupled with other parts of the operating system, violating the UNIX philosophy of "keep simple, keep stupid".
SYSTEMD Frame composition
Third, service management
1, Systemctl
Systemctl is the primary command for SYSTEMD, which manages the system.
Centos 7:service Unit
Note: Can be compatible with earlier service scripts
Command format
#systemctl COMMAND Name.service
Rebooting the system
# Systemctl reboot
Shut down the system, cut off the power
# Systemctl Poweroff
CPU stops working
# Systemctl Halt
Pause System
# Systemctl Suspend
Put the system into hibernation state
# Systemctl Hibernate
Put the system into an interactive hibernation state
# Systemctl Hybrid-sleep
Boot into rescue status (single user status)
# Systemctl Rescue
Start the service
#service name start ==> systemctl start Name.service
Stop Service
#service name Stop ==> systemctl stop Name.service
Restart Service
#service name Restart ==> systemctl Restart Name.service
View service Status
#service name status ==> systemctl status Name.service
Conditional restart: Started before restarting, otherwise do not operate
#service name Condrestart ==> systemctl Tryrestart name.service
Reload or restart service: Load first, then start
#systemctl Reload-or-restart Name.service
Overloaded or conditional restart service:
#systemctl Reload-or-try-restart Name.service
Disable automatic and Manual startup:
#systemctl Mask Name.service
To cancel a ban:
#systemctl unmask Name.service
2, service view:
View the power-on status of all services:
chkconfig--list ==> systemctl List-unit-files--type Service
is used to list which runlevel the service is enabled and disabled under
Chkconfig sshd–list ==>ls/etc/systemd/system/*.wants/sshd.service
To see if the service is powered on:
systemctl is-enabled name.service
other commands:
viewing dependencies for services:
systemctl list-dependencies name.service
kill Process:
systemctl Kill process name
Show all underlying parameters for a Unit
# systemctl Show Httpd.service
Displays the value of the specified property of a Unit
& nbsp; # systemctl show-p cpushares httpd.service
set specified properties of a Unit
&nbs p; # sudo systemctl set-property httpd.service cpushares=500
3. Service Status:
Display status
Systemctl list-unit-files--type Service–all
Loaded:unit configuration file has been processed
Active (running) run of one or more persistent processes
Active (exited) successfully completed one-time configuration
Active (waiting) running, waiting for an event
Inactive does not run
Enabled boot up
Disabled boot does not start
Static boot does not start, but can be activated by another enabled service
4, Hostnamectl
The HOSTNAMECTL command is used to view information about the current host.
Displays information about the current host
# Hostnamectl
Set the host name.
# Hostnamectl Set-hostname Rhel7
5, Localectl
The LOCALECTL command is used to view localization settings.
View localization Settings
# Localectl
# Set localization parameters.
# Localectl Set-locale Lang=en_gb.utf8
# Localectl Set-keymap EN_GB
6, Timedatectl
123456789 Timedatectl
The TIMEDATECTL command is used to view the current time zone settings.
View Current time zone settings
Show all available time zones
# Timedatectl List-timezones
# Set the current time zone
$# Timedatectl Set-timezone America/new_york
# Timedatectl Set-time Yyyy-mm-dd
# Timedatectl Set-time HH:MM:SS
7, Loginctl
The LOGINCTL command is used to view the currently logged on user.
# List Current session
# Loginctl List-sessions
# list The currently logged in user
# Loginctl List-users
# Lists information that displays the specified user
# Loginctl Show-user (RUANYF) users
The
Four, unit
Systemd can manage all resources in the system. The different resources are collectively referred to as Unit (units). The unit represents different types of Systemd objects, through the configuration file process identity and configuration, and the file contains system services, listener sockets, saved system snapshots, and other init-related information. The
1, Unit type
Unit is divided into 12 types.
sysstemctl –t Help View unit type
Service unit: file name extension. Service, which defines the system service
Target unit: file name extension to. Target, which is used to simulate the implementation of the "RunLevel"
Device Unit:. Device, which defines the file kernel recognition device
Mount unit:. Mount defines the file system mount point.
Socket unit:. Socket, which identifies the socket file used for interprocess communication, or delays the start of the service at system startup, enabling on-demand startup
Snapshot unit:. Snapshot, managing system snapshots
Swap unit :. Swap, which identifies the swap device
AutoMount unit:. AutoMount, automatic mount point for file system
Path unit:. Path, used to define a file or directory used in the file system, often used when the file system changes, Deferred activation services, such as: Spool directory
Scope unit: External process not initiated by SYSTEMD
Slice Unit: Process Group
Timer Unit: Timer
2. Systemctl list-units command to view all the Unit of the current system.
List the running Unit
# Systemctl List-units
List all the unit, including the configuration file not found or failed to start
# Systemctl List-units--all
List all non-running Unit
# systemctl List-units--all--state=inactive
List all Unit that failed to load
# Systemctl List-units--failed
List all running, service-type Unit
# Systemctl List-units--type=service
3. Unit status
The SYSTEMCTL status command is used to view the state of the system and the status of a single Unit.
Show System Status
#systemctl status
Displays the status of a single Unit
# SYSYSTEMCTL Status Bluetooth.service
Displays the status of a Unit of a remote host
# systemctl-h [email protected] status Httpd.service
In addition to the status command, SYSTEMCTL provides a simple way to query the state of three, primarily for use within the script's internal judgment statements.
Shows if a Unit is running
# Systemctl Is-active Application.service
Shows if a Unit is in a startup failure state
# Systemctl is-failed Application.service
Shows if a Unit service has a startup link established
# Systemctl is-enabled Application.service
4. Dependency relationship
There is a dependency between the Unit: A depends on B, which means that the Systemd starts at a and starts B.
#systemctl list-dependencies command lists all dependencies for a Unit.
# Systemctl List-dependencies Nginx.service
In the output of the above command, some dependencies are Target types (see below), which are not displayed by default. If you want to expand Target, you need to use the--all parameter.
# systemctl List-dependencies--all Nginx.service
V. Unit configuration file
1. Overview
Each unit has a configuration file that tells Systemd how to start the unit.
Systemd reads the configuration file from the directory/etc/systemd/system/by default. However, most of the files that are stored inside are symbolic links, pointing to the directory/usr/lib/systemd/system/, and the real configuration files are stored in that directory.
The Systemctl enable Httpd.service command is used to establish a symbolic link relationship between the above two directories. (Created symlink From/etc/systemd/system/multi-user.target.wants/httpd.service to/usr/lib/systemd/system/ Httpd.service.) is equivalent to Ln-s/usr/lib/systemd/system/httpd.service/etc/systemd/system/multi-user.target.wants/ Httpd.service. Of course Systemdctl Diable Httpd.service is equivalent to deleting this soft connection.
/usr/lib/system/system: The primary startup script setting for each service, similar to the previous/etc/init.d/
/run/system/system: The service script generated during the execution of the system, with priority running on the above directory.
/etc/systemd/system: An administrator-created execution script, similar to the/ETC/RC.D/RCN.D/SXX function, is preferred to run than the above directory.
2. configuration file Status
The Systemctl list-unit-files command is used to list all configuration files.
List all configuration files
#systemctl List-unit-files
Lists profiles of the specified type
#systemctl List-unit-files--type=service
SYSTEMCTL list-unit-files the command outputs a list from which you can see the status of each configuration file.
Unit config filestatus
lvm2-lvmetad.service Disabled
lvm2-lvmetad.socket enabled
lvm2-lvmpolld.service Disabled
lvm2-lvmpolld.socket enabled
This list shows the status of each profile, with a total of four.
Enabled: A startup link has been established
Disabled: No startup link established
Static: The configuration file does not have a [Install] section (cannot be executed) and can only be relied upon for other configuration files
Masked: The configuration file is blocked from establishing a startup link
Note that the status of the configuration file cannot be seen whether the Unit is running. This must perform the Systemctl status command mentioned earlier.
# SYSTEMCTL Status Httpd.service
3. Configuration file format
1) Unit configuration file format
[Unit]
Description=backup/etc
Requires=atd.service
[Service]
Type=simple
Execstart=/bin/bash-c "Echo/testdir/bak.sh|at Now"
[Install]
Wantedby=multi-user.target
[Unit]: Defines a common option independent of the unit type; used to provide descriptive information about the unit, unit behavior, dependencies, etc.
[Service]: A specialized option related to a specific type; service Type here
[Install]: Defines some of the options used by the "systemctl enable" and "systemctl disable" commands when enabling or disabling a service
2. Common options for Unit segment: Description: Short Description
Description: Description Information
After: Defines the start order of the unit, which indicates what the current unit should be later than
Unit is activated, and its function is opposite to before
Requires: The current unit cannot be activated when a dependent units cannot be activated, depending on the other units that it relies on
Wants: Dependent on the other units, weak dependence
Conflicts: Defining a conflict relationship between units
Bindsto: Similar to requires, the unit specified by it exits, causing the current unit to stop running
Before: If the unit specified in this field is to be started, it must be started after the current unit
Conflicts: The unit specified here cannot be run concurrently with the current unit
Condition ... : The current Unit operation must meet the conditions, otherwise it will not run
Assert... : The current Unit operation must meet the conditions, otherwise it will be reported to start failure
3. Service-Common options
Type: The unit process startup types that define features that affect Execstart and related parameters
Simple: The default value, this daemon is mainly initiated by the Execstart-connected instruction string, and is resident in memory after startup.
Forking: The program initiated by Execstart extends the other subroutines through spawns as the main service of this daemon. The original Father program terminates at the end of the launch.
OneShot: Similar to simple, but this program is finished after the work is finished, will not reside in memory
Dbus: Similar to simple, but this daemon must be given a d-bus name before it continues to work. So it's usually necessary to set the busnname= at the same time.
Notify: A notification message is sent when the boot is complete. You also need to cooperate with notifyaccess to get Systemd to receive messages
Idle: Similar to simple, to perform this daemon must be performed after all the work has been performed successfully. This type of Daemon pass
It is often a service that is powered on to the last minute.
Environmentfile: Environment configuration file
Execstart: Indicates the absolute path of the start unit to run a command or script
Run before Execstartpre:execstart
Run after Execstartpost:execstart
Execrsload: Commands executed when restarting the current service
Execstoppost: Commands executed after stopping the current service
EXECSTARTSEC: Automatically restarts the number of seconds in the current service interval
Execstop: Indicates the command or script that stops the unit to run
Restart: When Restart=1 is set, the service is automatically started again when the daemon service terminates unexpectedly.
TIMEOUTSEC: Defines the number of seconds to wait before Systemd stops the current service.
Environment: Specifies the environment variable.
4. Install common options
Common options for the install segment:
Alias: aliases, you can use SYSTEMCTL command alias.service
Requiredby: What units rely on, strong dependence
Wantedby: What units depends on, weak dependence
Also: When installing this service, we also need to install other related services.
Note: For newly created unit files, or modified unit files, to notify Systemd to reload this profile, you can then choose to restart.
# Systemctl Daemon-reload
# Systemctl Daemon-reload
#systemctl Restart Httpd.service
For more detailed unit configuration file formats please refer to the official documentation
Https://www.freedesktop.org/software/systemd/man/systemd.unit.html
VI. Target
When you start the computer, you need to start a large number of Unit. If you start each time, it is obviously inconvenient to specify which Unit is required for this launch. The SYSTEMD solution is Target.
Simply put, Target is a unit group that contains a number of related units. When you start a Target, SYSTEMD will start all of the Unit inside. In this sense, the concept of target is similar to the "State point", and starting a target is like booting into a state.
In the traditional init startup mode, there is the concept of RunLevel, which is similar to the role of Target. The difference is that RunLevel is mutually exclusive and it is not possible to start multiple RunLevel simultaneously, but multiple Target can be started simultaneously.
1. Target command
View all Target for current system
# Systemctl List-unit-files--type=target
View all Unit contained in a Target
# Systemctl List-dependencies Multi-user.target
To view the default Target at startup
# Systemctl Get-default
Set the default Target at startup
# Systemctl Set-default Multi-user.target
When switching target, the process that the previous target starts is not closed by default, the Systemctl isolate command changes this behavior,
Closes all processes in the previous target that do not belong to the latter target Systemctl isolate Multi-user.target
2. The corresponding relationship between target and traditional RunLevel is as follows.
Traditional RunLevel New target name symbolically linked to ...
Runlevel 0 | Runlevel0.target-Poweroff.target
Runlevel 1 | Runlevel1.target-Rescue.target
Runlevel 2 | Runlevel2.target-Multi-user.target
Runlevel 3 | Runlevel3.target-Multi-user.target
Runlevel 4 | Runlevel4.target-Multi-user.target
Runlevel 5 | Runlevel5.target-Graphical.target
Runlevel 6 | Runlevel6.target-Reboot.target
3. The main differences between it and the Init process are as follows.
(1) The default RunLevel (in the/etc/inittab file setting) is now replaced by the default Target, and the location is/etc/systemd/system/ Default.target, usually symbolic links to Graphical.target (graphical interface) or Multi-user.target (multi-user command line).
(2) The location of the startup script, formerly the/ETC/INIT.D directory, is linked to a different RunLevel directory (such as/ETC/RC3.D,/ETC/RC5.D, etc.) and is now stored in/lib/systemd/system and/etc/ Systemd/system directory.
(3) The location of the configuration file, the configuration file of the previous Init process is/etc/inittab, and the configuration files of various services are stored in the/etc/sysconfig directory. Now the configuration file is mainly stored in the/LIB/SYSTEMD directory, the changes in the/ETC/SYSTEMD directory can overwrite the original settings.
Vii. Log Management
SYSTEMD Unified management of all Unit startup logs. The benefit is that you can view all logs (kernel logs and application logs) with just one command of Journalctl. The configuration file for the log is/etc/systemd/journald.conf.
1, Journalctl powerful, use very much.
View all logs (by default, only the log for this startup is saved)
# Journalctl
View kernel log (does not show application log)
# journalctl-k
View the log of the system startup
# Journalctl-b
# journalctl-b-0
View the last log that was started (you need to change the settings)
# Journalctl-b-1
View logs for a specified time
# journalctl--since= "2012-10-30 18:17:16"
# journalctl--since "min ago"
# Journalctl--since Yesterday
# journalctl--since "2015-01-10"--until "2015-01-11 03:00"
# journalctl--since--until "1 hour Ago"
Show the latest 10 rows of logs at the trailer
# Journalctl-n
Displays a log of the specified number of rows in the trailer
# Journalctl-n 20
Real-time scrolling shows the latest logs
# journalctl-f
View logs for a specified service
# JOURNALCTL/USR/LIB/SYSTEMD/SYSTEMD
To view the logs for a specified process
# Journalctl _pid=1
To view the log of a script for a path
# Journalctl/usr/bin/bash
View logs for a specified user
# Journalctl _uid=33--since today
View a log of a Unit
# journalctl-u Nginx.service
# journalctl-u Nginx.service--since today
Real-time scrolling shows the latest log for a Unit
# journalctl-u Nginx.service-f
Merge displays logs for multiple Unit
# journalctl-u Nginx.service-u Php-fpm.service--since today
2. View the logs of the specified priority (and above) in a total of 8 levels
0:emerg
1:alert
2:crit
3:err
4:warning
5:notice
6:info
7:debug
# journalctl-p Err-b
Log default paging output,--no-pager changed to normal standard output
# Journalctl--no-pager
Output in JSON format (single line)
# journalctl-b-U nginx.service-o JSON
Output in JSON format (multiple lines) for better readability
# journalctl-b-U nginx.serviceqq
-O Json-pretty
Show the disk space occupied by the log
# Journalctl--disk-usage
Specifies the maximum space occupied by the log file
# Journalctl--VACUUM-SIZE=1G
Specify how long log files are saved
# Journalctl--vacuum-time=1years
Systemd detailed in CentOS 7