Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use the systemctl command in linux. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

1. Introduction of systemctl

In general, the init process is always used to start Linux.

We often see

$sudo / etc/init.d/apache2 start

Or

$service apache2 start

This approach has two disadvantages:

First, it takes a long time to start. The init process is started serially, and the next process will not be started until the previous process has been started.

Second, the startup script is complex. The init process simply executes the startup script, regardless of anything else. Scripts need to deal with a variety of situations on their own, which often makes them very long.

For this reason, Systemd is introduced into LINXU design.

Its design goal is to provide a complete solution for the startup and management of the system. According to Linux convention, the letter d is an abbreviation for daemon (daemon). The name Systemd means that it protects the entire system. With Systemd, you don't need to use init anymore. Systemd replaces initd as the first process of the system (PID equals 1), and all other processes are its children.

With the command in the figure above, we can view the Systemd version.

Generally speaking, the advantages of Systemd are powerful and easy to use, while the disadvantage is that the system is huge and very complex. In fact, there are still many people who oppose the use of Systemd on the grounds that it is too complex, strongly coupled with the rest of the operating system, and violates the Unix philosophy of "keep simple, keep stupid".

The picture above is the architecture of Systemd, which looks a little scary!

II. Systemctl command

Systemd is not a command, but a set of commands that cover all aspects of system management.

Let me introduce a few commonly used commands.

# start the redis service

$sudo systemctl start redis

# restart redis service

$sudo systemctl restart redis

# View the status of redis service

$sudo systemctl status redis

# restart the system

$sudo systemctl reboot

# shut down the system and cut off the power

$sudo systemctl poweroff

Third, add custom services using systemctl

In daily development, we inevitably build a variety of services, at this time, we can use systemctl to add the services we need.

Take my system as an example, the configuration service can be found in the directory shown above. System stores the service configured by the system, and the user directory stores the service configured by the user. Of course, you can also put the service in system.

The picture above shows the ECF service that has been built, with three keywords Unit, Service and Install.

[Unit]

Description: a brief description of the service

Documentation: service documentation

Before, After: define the startup order. Before=xxx.service, which means that this service is started before xxx.service starts. After=xxx.service, which represents that this service starts after xxx.service.

Requires: when this unit starts, the unit it needs will also be started; the unit it needs is stopped, and the unit is stopped.

Wants: recommended. When the unit is started, the unit it needs will also be started; the unit it needs is stopped and has no effect on the unit.

[Service]

Type=simple (default): systemd believes that the service will start immediately. The service process will not fork. If the service is going to start other services, do not start using this type unless the service is socket-activated.

Type=forking:systemd believes that the service starts successfully when the service process fork and the parent process exits. For regular daemons (daemon), unless you are sure that this startup method does not meet the requirements, you can use this type of startup. Using this startup type, you should also specify PIDFile=, so that systemd can track the main process of the service.

Type=oneshot: this option applies to services that perform only one task and then exit immediately. You may need to set RemainAfterExit=yes at the same time so that systemd still thinks the service is active after the service process exits.

Type=notify: same as Type=simple, but the contract service sends a signal to systemd when it is ready. The implementation of this notification is provided by libsystemd-daemon.so.

Type=dbus: if started in this way, systemd thinks the service is ready when the specified BusName appears on the DBus system bus.

Type=idle: systemd waits for all task (Jobs) processing to complete before starting to execute a unit of type idle. In addition, other behaviors are similar to Type=simple.

PIDFile:pid file path

ExecStart: specifies the command or script of the startup unit, and the ExecStartPre and ExecStartPost sections specify scripts that are customized by the user before or after ExecStart. Type=oneshot allows you to specify multiple user-defined commands that you want to execute sequentially.

ExecReload: specifies the command or script to execute when the unit stops.

ExecStop: specifies the command or script to execute when the unit stops.

PrivateTmp:True represents a separate temporary space allocated to the service

Restart: if this option is allowed, the process will exit when the service is restarted, and the cleanup and restart will be performed through the systemctl command.

RemainAfterExit: if you set this selection to true, the service will be considered to be active, even if all processes have exited, and the default value is false. This option needs to be configured only when Type=oneshot.

[Install]

Alias: provides an additional name for the unit that is spatially separated.

RequiredBy: the unit is allowed to run a series of dependent units needed, and the RequiredBy list gets the dependency information from the Require.

WantBy: the unit is allowed to run the weak dependency unit needed, and Wantby gets the dependency information from the Want list.

Also: indicates the unit that is installed or assisted with the unit.

DefaultInstance: restrictions on instance units, this option specifies if the unit is allowed to run the default instance.

This is the end of this article on "how to use systemctl commands in linux". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.