Systemd is an initialization system and service manager for the Linux operating system. It is responsible for starting and managing various services and processes in the system. It was developed by Lennart Poettering and released as open source under the LGPL 2.1 and its subsequent versions. Systemd has been widely adopted by most mainstream Linux distributions, such as Ubuntu, Fedora, and Debian. The i.MX6/8/9 series on the AIoT lab uses a customized Linux version, namely the Yocto system, which also uses the systemd manager.
The systemctl command is a command line tool for the systemd system. It provides powerful management capabilities for system processes by controlling and monitoring system services and unit files.
When debugging on a development board, we may want to set some commands or script files to start automatically at boot. This can improve debugging efficiency, especially when running the same command multiple times to see the results. We can use systemd to set commands or script files to start automatically at boot.
This document includes:
• Use Systemd to set the program start automatically at boot
1. Book the board:
2. As mentioned above, the systemctl command is a command-line tool for the systemd system and service manager. When the Linux system starts, the kernel loads and executes the first user space program, systemd. It runs as PID 1 and is the parent process of all other processes. Systemd reads configuration files, which are usually located in /etc/systemd/system and /lib/systemd/system, with the suffix .service, and starts services in parallel or sequentially according to the order of dependency.
The basic syntax of the systemctl command is:
systemctl [OPTIONS...] COMMAND [UNIT]
Among them, OPTIONS is an optional parameter used to specify the behavior of systemctl; COMMAND is a required parameter used to execute a specific systemd command, such as starting, stopping, or restarting a service; UNIT is an optional parameter used to specify the service or unit to operate.
Such as:
Start the service:
systemctl start <service name>.service
Stop the service:
systemctl stop <service name>. service
Restart the service：
systemctl restart <service name> .service
Check the service status:：
systemctl satus<service name>.service
Set the service to start automatically at boot:
systemctl enable<service name>.service
Cancel the service to start automatically at boot:：
systemctl disable<service name>.service
List all enabled services:
systemctl list-unit-files --state=enabled
Reload the service configuration file:
After modifying the service configuration file (such as myservice.service as below), you need to execute this command to reload the configuration file.
systemctl daemon-reload
3. “Units” designed by systemd are configuration files used to describe system resources and services. They represent different types of objects that systemd can manage. The main unit types supported by systemd are:
(1) Service unit (.service): This is the most commonly used unit type, used to define system services, such as daemons and their related processes. Service units control the start, stop, and reload of services.
(2) Socket unit (.socket): used to manage local IPC (inter-process communication) or network sockets in the system, and supports socket-based activation of services, that is, automatically starting the corresponding service when there is a connection request on the socket.
(3) Target unit (.target): A set of units used to define the system state or run level, such as multi-user target (multi-user.target) or graphical interface target (graphical.target). Switching a target actually starts or stops a set of services associated with the target.
(4) Device unit (.device): represents a hardware device in the system and can be used for device-based activation, that is, performing specific operations when a device is connected or removed.
In addition, there are mount units (.mount), path units (.path), timer units (.timer), swap units (.swap), automatic mount point units (.automount), etc.
The service unit (.service) is the most commonly used unit type. Take psplash-start.service under /lib/systemd/system as an example. This service unit will display an open-embedded image on the screen before Weston starts.
vi /lib/systemd/system/psplash-start.service
[Unit]
Description=Start Psplash Boot Screen
Wants=systemd-vconsole-setup.service
After=systemd-vconsole-setup.service systemd-udev-trigger.service systemd-udevd.service
DefaultDependencies=no
[Service]
ExecStartPre=/bin/sh -c "if [ -e /sys/class/graphics/fbcon/cursor_blink ]; then echo 0 > /sys/class/graphics/fbcon/cursor_blink; fi"
ExecStart=/bin/sh -c "s=$(/usr/sbin/fbset -i -fb /dev/fb0 | grep epdc); if [ -z "$s" ]; then i=0; else i=1; fi; if [ -e /dev/fb$i ]; then /usr/bin/psplash -n
[Install]
The .service file is divided into three parts:
(1) [Unit] part, which describes the data and dependencies of the unit.
1) Description: Description of the current service.
2) After and Before: Defines the startup order of the services, indicating which services the current service should be started after or before. These two fields only involve the startup order, not the dependencies.
3) Wants: Indicates that there is a weak dependency between the current service and another service. If the other service fails to start or stops running, it will not affect the continued execution of the current service.
4) Requires: Indicates that there is a strong dependency between the current service and another service. If the other service fails to start or exits abnormally, the current service must also exit.
5) Conflicts: Defines the services that conflict with the current service. If the conflicting service has been started, the current service cannot be started.
(2) [Service] part: Defines the specific behavior of the service.
1) ExecStart: Defines the command to be executed when the service starts. It can be a single command, a script file, or a script composed of multiple commands.
2) ExecStop: Defines the command to be executed when the service stops.
3) ExecStartPre and ExecStopPost: DefineS the commands to be executed before and after the service is started.
4) WorkingDirectory: Dpecifies the working directory of the service.
5) User and Group: specify the user and group under which the service runs.
6) Restart and RestartSec: Defines the restart policy of the service, such as whether to restart automatically, the restart interval, etc.
(3) [Install] section: Defines how to install the service into the system.
7) WantedBy and RequiredBy: DefineS which services or targets need or require the current service.
8) Alias: Defines an alias for the service.
2. Taking the 8MPLUSLPD4-PEVK-3 development board as an example, the default CPU frequency policy is ondemand (normally running at a low speed, and automatically increasing the frequency on demand when the system load increases). We want to set the CPU frequency policy to powersave when the computer starts automatically, that is, running at the lowest frequency.
First check the default CPU frequency:
cat /sys/kernel/debug/clk/clk_summary|grep arm
You can see that the CPU frequency is 1.8GHz (highest) most of the time, and occasionally runs at 1.6GHz. If you run the following command manually, the CPU frequency policy is powersave, that is, running at the lowest frequency:
cpufreq-set -g powersave
You can see that the CPU frequency has become 1.2GHz, which is the lowest frequency.
We now add a new service called “my service” in systemd and set the CPU frequency policy to the powersave command to start automatically at boot.
First, create a script file named cpufreq.sh under /home/root and set the script permission to the highest 777:
#!/bin/bash
cpufreq-set -g powersave
cpufreq-info
In the /etc/systemd/system path, create a file named myservice.service with the following content:
[Unit]
Description=My service
After=weston.service
[Service]
ExecStart=/home/root/cpufreq.sh
User=root
[Install]
WantedBy=multi-user.target
ExecStart means that the script /home/root/cpufreq.sh will be executed when the service starts.
Run the following commands in sequence:
systemctl daemon-reload
systemctl enable myservice.service
systemctl start myservice.service
Then click PowerReset-EVK button to restart the development board. Before board login, you can see that My service starts automatically after Weston service starts. Check the CPU frequency and you can see that the CPU frequency has been set to the minimum of 1.2GHz, which proves that the program auto-start setting through systemd has taken effect.
Note that when running below command:
systemctl status myservice
You will see that the status of myservice is inactive (dead), indicating that the service has stopped.
This is because the command in cpufreq.sh called by ExecStart is just a command, not a service program, and does not have a loop. It ends after the computer is started. If we modify cpufreq.sh to:
#!/bin/bash
while true;do
cpufreq-set -g powersave
cpufreq-info
done
And run the following commands in sequence:
systemctl daemon-reload
systemctl enable myservice.service
systemctl restart myservice.service
Then run
systemctl status myservice
After checking, you will see that the status of myservice changes from inactive (dead) to active. After the development board is restarted, this status is still active.
If you want to cancel the automatic startup of myservice, run
systemctl disable myservice.service
Then restart, you can see that the log “[ OK ] Started My service.” disappears in the startup log, and its status is disabled and inactive.
