Cheat Sheet Management Services CentOS 7 with systemd
Systemd is a system and services manager in the Linux operating system. When developing, they sought to design backwards compatible with the SysV init initialization scripts and provide useful features, such as parallel launch of system services at boot time, activation of daemons on demand, support for system state snepshots, and dependency-based service management logic. On CentOS 7, systemd replaces Upstart as the default init system.
In this article we will look at the process of managing services in systemd for a CentOS 7 user. This knowledge will also be useful in other distributions, because systemd has been used in Fedora for a long time and is planned in Ubuntu 14.10 and Debian 8. Good or not, we'll leave it behind the scenes.
')
In the process of reading the article, you can try systemd on classic VPS and cloud VPS from Infobox. We strive to add support for modern operating systems in a timely manner so that you can use the latest technologies for more efficient operation. The very idea of writing the article was born after another user question about the use of services in CentOS 7.
Systemd brings the concept of systemd units. Units are represented by configuration files located in one of the directories:
Units contain information about system services, listening sockets, saved snapshots of system states and other objects related to the initialization system.
Systemd unit types:
In previous versions of CentOS, SysV or Upstart was used. Initialization scripts were located in the /etc/rc.d/init.d/ directory. Such scripts were usually written on Bash and allowed the administrator to manage the state of services and daemons. In CentOS 7, the initialization scripts were replaced by service units.
By the way of using, service units .service resemble initialization scripts. To view, start, stop, restart, enable or disable system services, use the systemctl command. The service and chkconfig commands are still included in the system, but only for compatibility reasons.
When using systemctl, it is not necessary to specify the file extension.
The following are the main systemctl commands :
Previous versions of CentOS with SysV init or Upstart included a predefined set of launch levels (runlevels) that represented specific modes for operations, numbered from 0 to 6. In CentOS 7, the concept of launch levels was replaced by systemd targets.
The systemd .target target files are intended to group together other systemd units through a chain of dependencies. For example, the graphical.target unit, used to start a graphics session, starts the GNOME Display Manager ( gdm.service ) and Accounts Service ( accounts – daemon.service ) system services and activates multi-user.target . In turn, multi–user.target launches other system services, such as Network Manager ( NetworkManager.service ) or D-Bus ( dbus.service ), and activates other target units of basic.target .
CentOS 7 has predefined targets, similar to the standard set of launch levels. For compatibility reasons, they also have aliases for these purposes, which are directly displayed in the SysV launch levels.
The runlevel and telinit commands are still available, but left on the system for compatibility reasons. It is recommended to use systemctl to modify or configure system targets.
To determine which target unit is used by default, the following command is useful: systemctl get – default .
To view all loaded target units, use the systemctl list-units - type target command , and to view all target units in general with the command: systemctl list-units --type target --all .
To change the default target, use the systemctl command set-default name.target .
To change the current target: systemctl isolate name.target . The team will launch the target unit and all its dependencies and immediately stop all the others.
On CentOS 7, the systemctl replaces a significant number of power management commands. The former commands are kept for compatibility, but it is recommended to use systemctl:
systemctl halt - stops the system
systemctl poweroff - shuts down the system
systemctl reboot - reboot the system
Systemd allows you to control a remote machine via SSH. To manage, use the command:
systemctl --host user_name @ host_name command , where user_name is the user name, host_name is the name of the host that is being remotely managed, and command is the executable systemd command.
This section will help you if you need to quickly make support for service management from systemd. Detailed information on all the parameters of the .service file is in the corresponding section of the systemd documentation.
Let's take a look at the [Unit] section. It contains general information about the service. This section is not only in service units, but also in other units (for example, when controlling devices, mount points, etc.). In our example, we give a description of the service and indicate that the daemon should be running after Syslog.
The next section [Service] directly contains information about our service. The ExecStart parameter used points to the executable file of our service. In Type, we specify how the service notifies systemd when the launch is complete.
The final [Install] section contains information about the target for which the service should start. In this case, we say that the service should be started when the goal of multi–user.target is activated.
This is the minimum operating systemd service file. After writing your own, for testing, copy it into /etc/systemd/system/service_service.service. Run the systemctl daemon-reload commands. Systemd finds out about the service and you can start it.
An excellent systemd guide from RedHat that forms the basis of this article.
Documentation on writing your systemd service unit .
"Systemd for administrators" from the systemd developer in Russian.
In this article, we learned how to manage CentOS 7 services. Of course, this is not the only systemd function and its other sides will be considered in the future. OS itself almost from the time of release is available on classic VPS and cloud VPS from Infobox. Try systemd right now. This knowledge will be useful in connection with the transition of many distributions to systemd.
If you find an error in the article, the author will gladly correct it. Please write in the LAN or in the mail about it.
In case you cannot post comments on Habré, you can write them in the InfoboxCloud Community blog or in our group on Facebook .
Successful use of CentOS 7!
In this article we will look at the process of managing services in systemd for a CentOS 7 user. This knowledge will also be useful in other distributions, because systemd has been used in Fedora for a long time and is planned in Ubuntu 14.10 and Debian 8. Good or not, we'll leave it behind the scenes.
')
In the process of reading the article, you can try systemd on classic VPS and cloud VPS from Infobox. We strive to add support for modern operating systems in a timely manner so that you can use the latest technologies for more efficient operation. The very idea of writing the article was born after another user question about the use of services in CentOS 7.
Introduction
Systemd brings the concept of systemd units. Units are represented by configuration files located in one of the directories:
- / usr / lib / systemd / system / - units from installed RPM packages.
- / run / systemd / system / - units created in runtime. This directory is more priority than the directory with installed units from the packages.
- / etc / systemd / system / - units created and managed by the system administrator. This directory is more priority than the directory of units created in runtime.
Units contain information about system services, listening sockets, saved snapshots of system states and other objects related to the initialization system.
Systemd unit types:
- .service - system service
- .target - systemd unit group
- .automoun t - file system auto-mount point
- .device - the device file recognized by the kernel
- .mount - file system mount point
- .path - file or directory in the file system
- .scope - a process created externally
- .slice - a group of hierarchically organized units that controls system processes
- .snapshot - systemd manager's saved state
- .socket - interprocess communication socket
- .swap - SWAP device or swap file (paging file)
- .timer - systemd timer
The main systemd functions in CentOS 7
- Socket based activation . At boot time, systemd listens for sockets for all system services, supports this type of activation, and transfers sockets to these services immediately after starting the services. This allows systemd to not only start services in parallel, but also makes it possible to restart services without losing any messages sent to them while the services were unavailable. The corresponding socket remains available and all messages are lined up.
- D-Bus based activation . System services that use D – Bus for interprocess communication can be started on demand when a client application tries to communicate with them.
- Activation based on devices . System services that support device-based activation can be started when a certain type of equipment is connected or becomes available.
- Path based activation . System services can support this type of activation if the state of a folder or directory changes.
- Nepshot system states . The system can save the state of all units and restore the previous state of the system.
- Manage mount and automount points . Systemd tracks and manages mount and automount points.
- Aggressive parallelization Systemd runs system services in parallel due to the use of socket-based activation. In combination with services that support on-demand activation, parallel activation significantly reduces system load time.
- Transactional activation logic units . Before activating and deactivating units, systemd calculates their dependencies, creates a temporary transaction and checks the integrity of this transaction. If the transaction is not complete, systemd automatically tries to correct it and remove unnecessary tasks from it before generating an error message.
- Backward compatibility with SysV initialization . SystemD fully supports SysV init scripts as described in the Linux Standard Base specification (LSB), which simplifies the transition to systemd.
Service Management
In previous versions of CentOS, SysV or Upstart was used. Initialization scripts were located in the /etc/rc.d/init.d/ directory. Such scripts were usually written on Bash and allowed the administrator to manage the state of services and daemons. In CentOS 7, the initialization scripts were replaced by service units.
By the way of using, service units .service resemble initialization scripts. To view, start, stop, restart, enable or disable system services, use the systemctl command. The service and chkconfig commands are still included in the system, but only for compatibility reasons.
When using systemctl, it is not necessary to specify the file extension.
The following are the main systemctl commands :
- systemctl start name.service - start the service.
- systemctl stop name.service - service stop
- systemctl restart name.service - restart service
- systemctl try-restart name.service - restart the service only if it is running
- systemctl reload name.service - reload service configuration
- systemctl status name.service - check whether the service is running with a detailed display of the status of the service
- systemctl is-active name.service - check if the service is running with a simple answer: active or inactive
- systemctl list-units - type service - all - display the status of all services
- systemctl enable name.service - activates the service (allows you to start during system startup)
- systemctl disable name.service - deactivates the service
- systemctl reenable name.service - deactivates the service and immediately activates it
- systemctl is – enabled name.service - checks if the service is activated
- systemctl list-unit-files --type service - displays all services and checks which ones are activated.
- systemctl mask name.service - replaces the service file with a symlink for / dev / null, making the unit inaccessible for systemd
- systemctl unmask name.service - returns the service file, making the unit available to systemd
We work with targets (targets) Systemd
Previous versions of CentOS with SysV init or Upstart included a predefined set of launch levels (runlevels) that represented specific modes for operations, numbered from 0 to 6. In CentOS 7, the concept of launch levels was replaced by systemd targets.
The systemd .target target files are intended to group together other systemd units through a chain of dependencies. For example, the graphical.target unit, used to start a graphics session, starts the GNOME Display Manager ( gdm.service ) and Accounts Service ( accounts – daemon.service ) system services and activates multi-user.target . In turn, multi–user.target launches other system services, such as Network Manager ( NetworkManager.service ) or D-Bus ( dbus.service ), and activates other target units of basic.target .
CentOS 7 has predefined targets, similar to the standard set of launch levels. For compatibility reasons, they also have aliases for these purposes, which are directly displayed in the SysV launch levels.
- poweroff.target (runlevel0.target) - shutting down and shutting down the system
- rescue.target (runlevel1.target) - setting the recovery shell
- multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) - setting up a non-graphical multi-user system
- graphical.target (runlevel5.target) - setting up a graphical multi-user system
- reboot.target (runlevel6.target) - shutdown and reboot the system
The runlevel and telinit commands are still available, but left on the system for compatibility reasons. It is recommended to use systemctl to modify or configure system targets.
To determine which target unit is used by default, the following command is useful: systemctl get – default .
To view all loaded target units, use the systemctl list-units - type target command , and to view all target units in general with the command: systemctl list-units --type target --all .
To change the default target, use the systemctl command set-default name.target .
To change the current target: systemctl isolate name.target . The team will launch the target unit and all its dependencies and immediately stop all the others.
Shutting down and rebooting the system
On CentOS 7, the systemctl replaces a significant number of power management commands. The former commands are kept for compatibility, but it is recommended to use systemctl:
systemctl halt - stops the system
systemctl poweroff - shuts down the system
systemctl reboot - reboot the system
Managing systemd on a remote machine
Systemd allows you to control a remote machine via SSH. To manage, use the command:
systemctl --host user_name @ host_name command , where user_name is the user name, host_name is the name of the host that is being remotely managed, and command is the executable systemd command.
Typical systemd .service
This section will help you if you need to quickly make support for service management from systemd. Detailed information on all the parameters of the .service file is in the corresponding section of the systemd documentation.
[Unit] Description=Daemon to detect crashing apps After=syslog.target [Service] ExecStart=/usr/sbin/abrtd Type=forking [Install] WantedBy=multi-user.target Let's take a look at the [Unit] section. It contains general information about the service. This section is not only in service units, but also in other units (for example, when controlling devices, mount points, etc.). In our example, we give a description of the service and indicate that the daemon should be running after Syslog.
The next section [Service] directly contains information about our service. The ExecStart parameter used points to the executable file of our service. In Type, we specify how the service notifies systemd when the launch is complete.
The final [Install] section contains information about the target for which the service should start. In this case, we say that the service should be started when the goal of multi–user.target is activated.
This is the minimum operating systemd service file. After writing your own, for testing, copy it into /etc/systemd/system/service_service.service. Run the systemctl daemon-reload commands. Systemd finds out about the service and you can start it.
Additional Information
An excellent systemd guide from RedHat that forms the basis of this article.
Documentation on writing your systemd service unit .
"Systemd for administrators" from the systemd developer in Russian.
Conclusion
In this article, we learned how to manage CentOS 7 services. Of course, this is not the only systemd function and its other sides will be considered in the future. OS itself almost from the time of release is available on classic VPS and cloud VPS from Infobox. Try systemd right now. This knowledge will be useful in connection with the transition of many distributions to systemd.
If you find an error in the article, the author will gladly correct it. Please write in the LAN or in the mail about it.
In case you cannot post comments on Habré, you can write them in the InfoboxCloud Community blog or in our group on Facebook .
Successful use of CentOS 7!
Source: https://habr.com/ru/post/241237/
All Articles