This section describes some common service management modes in Linux

Service management

concept

A service is a function provided by a system that is implemented by a corresponding process, usually a resident daemon. Therefore, the term “service” is often used to refer to the corresponding system process

According to startup management, services can be divided into two categories: stand-alone and centrally managed; A standalone service, as the name implies, is a service that can be run alone, which is always in memory and can respond to requests immediately, such as WWW services. Centrally managed services, such as Telnet, require a special super daemon to wake up after receiving a request (calling the corresponding process into memory for execution). Signal driven By a signal, such as a request from a client, to make the service respond; A time driver executes at a fixed time

Service names are usually XXXD and end with the letter D

Historically, Linux has used init to start and thus manage services; Because of the shortcomings of init, most distributions now use Systemd to manage startup and services, as opposed to the tool Systemctl

init

Related directories /etc/init.d/ All service startup scripts are stored in this directory. /etc/sysconfig/services-related parameter files /etc/xinetd.conf && /etc/xinetd.d/ Stores super Daemon related service configurations /var/lib/stores the database generated by the service. /var/run/stores the pid of the service

Relevant command

#You can use the corresponding script directly for service management
#Format: / etc/init. D/servicename {start | stop | status | restart | condrestart}
#For example, to view the syslog service status:
/etc/init.d/syslog status

#It can also be managed using the service command (which is actually a script)
#Format for: service servicename {start | stop | status | restart | condrestart}
#For example, to view the syslog service status:
service syslog status
#View the current status of all services:
service --status-all
Copy the code

Super Daemon As mentioned above, services managed by super Daemon are scheduled by the xinetd daemon process. Xinetd itself is managed like other services that can be run independently. All services managed by xinetd have the default configuration /etc/xinetd.conf. The detailed configurations of each service are stored in the /etc/xinetd.d/ directory

The configuration format is as follows:

# assign_op # =: set this parameter to this value # +=: add this parameter to this value # -=: <servicename> {<attribute> <assign_op> <value> <value>... }Copy the code

The configuration parameters are as follows: Disable [yes | no] is started, the default is not to start,

id [Service name] Specifies the service name. Server [Program name] Specifies the absolute path of the startup program. Server_args [Start parameter] Specifies the parameter used to start the program Group] [user group account specified service belongs to a user group socket_type [stream | dgram | raw] protocol packet types [TCP] | udp protocol type wait yes | no default to no, Multi-user request whether need to queue for instances [UNLIMITED | digital] the maximum number of connections per_source [UNLIMITED | digital] the maximum number of connections of a single source IP CPS [two] said the first number within 1 s can accept new connections, Second number said beyond retry time log_type default log level life for info log_on_success [PID, the HOST, USERID, EXIT, DURATION] log_on_fail log in successfully log content [PID, the HOST, USERID, EXIT, DURATION] login failed log content env [name = value] process environment variables set port [number] redirect process port forwarding includedir/IP port service Bind [IP] Allows only the source IP address to access the file. Interface [IP] Same as only_from [0.0.0.0, 192.168.1.0/24, the hostname, domainname] ditto, accessible IP, does not restrict no_access 0.0.0.0 said [0.0.0.0 192.168.1.0/24, the hostname, domainname] again, Inaccessible IP Access_times [HH: mm-hh :MM] Specifies the 24-hour time period. Umask [000,777,022] Specifies the umask value

Service management

#Check whether the system service is started by default
# chkconfig --list [servicename]
#Such as:
chkconfig --list rsync

#This parameter is used to set the default startup status of the system service
# chkconfig --level [0123456] [servicename] [on|off]
#The level parameter specifies runlevel (a description of runlevel follows)
#Such as:
chkconfig --level 345 atd on
Copy the code

systemctl

As mentioned above, on most Linux distributions today, the Systemd service has replaced the initd service as the first process on the system (pid 1), and all other processes are its children; Systemd consists of a set of commands that design all aspects of system management. This section only covers service management

Systemd manages system resources (including system services) through units, which come in several types and are identified by a suffix:

Service unit Target unit Device unit Hardware Device Mount unit Automount unit Path unit Scope Unit: an external process not started by Systemd Slice Unit: a process group Snapshot Unit: a Systemd Snapshot, which can be switched back to a Snapshot Socket Unit: Socket Swap Unit: Swap file Timer Unit: TimerCopy the code

Systemctl is the main command of systemd. It can be used to manage services. The common commands are as follows:

# Start a service systemctl start servicename # Stop a service systemctl stop servicename # Restart a service systemctl restart servicename # Restart a service systemctl restart servicename # Systemctl reload servicename # Display the sysystemctl status of a single Unit (service) Status servicename # Displays whether a Unit is running systemctl is-active. Servicename # Displays whether a Unit is in the systemctl is-failed state Servicename # Displays whether a startup link is established for a Unit service. Systemctl is-enabled ServicenameCopy the code

Each Unit has its own startup configuration file, usually stored in /usr/lib/systemd/system/; When the system starts, it reads configuration files from the /etc/systemd/system/ directory. Therefore, systemd provides the systemctl enable command to set up a soft connection (systemctl disable deletes the soft connection). The default for the service

The profile content is made up of blocks, each of which is followed by a bunch of key-value pairs connected by the = (equal) sign: [unit]

Description: Documentation Requires: Other units that the current Unit depends on. If they are not running, the current Unit will fail to start. BindsTo: Similar to "Requires," which specifies a Unit that, if it exits, causes the current Unit to stop running Before: If the Unit specified by this field is also to be started, then After must be started: If the Unit specified by this field is also to be started, then Conflicts must be started before the current Unit: The Unit specified here cannot run Condition... : The condition that must be met for the current Unit to run, otherwise it will not run Assert... : Indicates the condition that the current Unit must meet when running. Otherwise, a startup failure message is displayedCopy the code

install

WantedBy: This value is one or more targets, and when the current Unit is enabled (enable) the symlink is RequiredBy in a subdirectory of the Target name +.wants suffix under the /etc/systemd/system directory: The value is one or more targets. When the current Unit is active, symbolic links are placed under the /etc/systemd/system directory in a subdirectory with the Target name +. Required Alias: the Alias used to start the current Unit. Other units that will be activated when the current Unit is enabledCopy the code

service

Type: Defines the process behavior at startup. It has the following values. Type=simple: The default value. Run the command ExecStart to start the main process. Type=forking: Fork the child process from the parent process, and the parent process exits immediately. Type=dbus: indicates that the current service is started using d-bus. Type=notify: Indicates that the current service is started. Type=notify: Indicates that the current service is started. ExecStart: the command used to start the current service ExecStartPre: the command used to start the current service ExecStartPost: the command used to start the current service ExecReload: the command used to start the current service ExecReload: the command used to start the current service ExecStop: command executed when the current service is stopped ExecStopPost: command executed after the service is stopped RestartSec: Number of seconds at which the current service is automatically restarted Restart: Define the circumstances in which Systemd automatically restarts the current service. Possible values include: always (always restart), on-success, on-failure, on-abnormal, on-abort, and on-watchdog TimeoutSec: Define the number of seconds that Systemd waits before stopping the current service Environment: Specifies the Environment variableCopy the code

Timing task

This paper introduces a tool crontab, which is used to schedule scheduled tasks. The service Crond schedules scheduled tasks and manages them using the crontab tool

When a user uses crontab to create a task, the task will be written to /var/spool/cron/and the user name will be used as the difference. The /etc/cron.allow configuration file is used to determine who can create a task. If the allow configuration does not exist, the /etc/cron.allow configuration file is used to determine who can create a task. Configure /etc/cron.deny to determine who cannot create a task. If no task exists, only root can

If the scheduled task is not specific to a user, but to the entire system, you can edit /etc/crontab

The command format

# crontab [-u username] [-l|-e|-r]
#-u Specifies the user. Only root can perform this operation
#-l Displays the current task
#-e Performs the editing task, and then enters the vi editing mode
#-r Deletes all tasks

crontab -e
#Then you will enter the edit mode, and the task format is as follows:
# * * * * * username command_to_be_executed
#The first five fields are time control, which are: minute, hour, day, month and week
#The time range is in the 24-hour system. In Week, 0 and 7 can indicate Sunday
#There are also some special symbols:
#*(asterisk) indicates any time
#,(comma) indicates parallel. For example,1,10, and 18 in the "Day" section indicates execution on 1,10, and 18
#Minus (minus) indicates the range
#/(slash) indicates intervals. For example, */5 in "divide" means every 5 minutes (used in conjunction with * or -)
Copy the code

Start the service

System startup process:

  1. Add hardware information in BIOS and self-check to get the first bootable device
  2. The bootLoader that executes the MBR (MasterBootRecord) in the first boot device, that is, the loader program
  3. Loading the system kernel
  4. The kernel adds RunLevel to the init(system) process
  5. The init(System) process loads various environments and services and waits for the user to log in

Most distributions today use the System program instead of init. The main differences are as follows:

  1. The default RunLevel (in/etc/inittabFile Settings) is now replaced by the default Target at/etc/systemd/system/default.target, usually symlinks tographical.target(graphical interface) ormulti-user.target(Multi-user command line)
  2. The location of the launch script, previously/etc/init.dDirectory, symbolic links to different RunLevel directories (e.g/etc/rc3.d,/etc/rc5.dEtc.), is now stored in/lib/systemd/systemand/etc/systemd/systemdirectory
  3. Location of the configuration file, previouslyinitThe process configuration file is/etc/inittab, the configuration files of various services are stored/etc/sysconfigDirectory. The current configuration files are mainly stored/lib/systemdDirectory,/etc/systemdChanges in the directory can override the original Settings. (in the/etc/inittabFile Settings) is now replaced by the default Target at/etc/systemd/system/default.target, usually symlinks tographical.target(graphical interface) ormulti-user.target(Multi-user command line)

Above, is this whole content, if there is insufficient, also please correct!

References: “bird brother Linux private house dishes ———— basic learning (the third edition)” Systemd introduction tutorial: command – Ruan Yifeng Systemd introduction tutorial: actual combat – Ruan Yifeng