diff --git a/docs/en/_toc.yaml b/docs/en/_toc.yaml new file mode 100644 index 0000000000000000000000000000000000000000..1731bf32f1ffd7e360bbf6e55913b60b9d838a54 --- /dev/null +++ b/docs/en/_toc.yaml @@ -0,0 +1,19 @@ +label: sysMaster User Guide +isManual: true +href: ./overview.md +description: Server and device management using sysMaster +sections: + - label: Service Management + href: ./service_management.md + sections: + - label: Installation and Deployment + href: ./sysmaster_install_deploy.md + - label: Usage Instructions + href: ./sysmaster_usage.md + - label: Device Management + href: ./device_management.md + sections: + - label: Installation and Deployment + href: ./devmaster_install_deploy.md + - label: Usage Instructions + href: ./devmaster_usage.md diff --git a/docs/en/device_management.md b/docs/en/device_management.md new file mode 100644 index 0000000000000000000000000000000000000000..0000f4c4ff28be245e065065cc5cb34ced0127d3 --- /dev/null +++ b/docs/en/device_management.md @@ -0,0 +1,14 @@ +# Device Management + +The device manager is a bridge between user-mode software and underlying physical devices, supporting the operation of key base software such as lvm2 and NetworkManager. As the device management component of sysMaster, devmaster supports quick startup of sysMaster and ecosystem compatibility of user-mode software. In addition, devmaster provides layered, decoupled, and scalable device management capabilities for common OSs based on the summary and contemplation of mainstream Linux device management solutions. + +devmaster consists of a daemon, a client tool, and a dynamic library. The devmaster daemon utilizes kernel mechanisms such as netlink, inotify, and sysfs to monitor device events and trigger rule processing tasks. The `devctl` client tool and **libs** dynamic library provide a set of CLI commands and public interfaces for debugging rules, controlling daemons, and querying device status. The following figure shows the overall architecture of devmaster. + +**Figure 1 devmaster overall architecture** +![devmaster_architecture](./figures/devmaster_architecture.png) + +devmaster is written in the Rust language to ensure memory safety. The core functions of devmaster are as follows: + +1. Event-driven operations: The queue cache and worker pool mechanisms are used to meet the requirements of highly concurrent device events. In addition, user-mode processes can be dynamically notified of the readiness of devices. +2. Separation of mechanisms and policies: Device processing logic is defined as rules rather than hard-coded in service code, allowing for on-demand customization and flexible combination. +3. Ecosystem compatibility: devmaster is compatible with the udev syntax and udev user-mode broadcast protocol. Existing services can be migrated to the devmaster environment with low costs. diff --git a/docs/en/devmaster_install_deploy.md b/docs/en/devmaster_install_deploy.md new file mode 100644 index 0000000000000000000000000000000000000000..e12ac33f71bd262de3d8df12c51fbeebecc9b682 --- /dev/null +++ b/docs/en/devmaster_install_deploy.md @@ -0,0 +1,68 @@ +# Installation and Deployment + +Currently, devmaster can be used in the VM environment. This section describes the requirements and procedure of devmaster installation and deployment. + +## Software + +* OS: openEuler 23.09 + +## Hardware + +* x86_64 or AArch64 architecture + +## Installation and Deployment + +1. Run the following `yum` command to install the sysmaster-devmaster package: + + ```shell + # yum install sysmaster-devmaster + ``` + +2. Run the following commands to create the default rule file **/etc/devmaster/rules.d/99-default.rules** and the daemon configuration file **/etc/devmaster/config.toml**: + + ```shell + # mkdir -p /etc/devmaster/rules.d + # mkdir -p /etc/devmaster/network.d + # echo "TAG+=\"devmaster\"" > /etc/devmaster/rules.d/99-default.rules + # cat << EOF > /etc/devmaster/config.toml + log_level = "info" + rules_d = ["/etc/devmaster/rules.d"] + network_d = ["/etc/devmaster/network.d"] + max_workers = 1 + log_targets = ["console"] + EOF + ``` + +3. Run the following commands to start the devmaster daemon and export logs to the **/tmp/devmaster.log** file: + + ```shell + # /lib/devmaster/devmaster &>> /tmp/devmaster.log & + ``` + + > ![Note](./public_sys-resources/icon-note.gif)**Note:** + > + > devmaster must be started with the root privilege and cannot be running with udev at the same time. Before starting devmaster, stop the udev service. + > + > If udev is started by sysMaster, run the following command: + + ```shell + # sctl stop udevd.service udevd-control.socket udevd-kernel.socket + ``` + + > If udev is started by systemd, run the following command: + + ```shell + # systemctl stop systemd-udevd.service systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket + ``` + +4. Run the following command to use the `devctl` tool to trigger a device event: + + ```shell + # devctl trigger + ``` + +5. Check the **/run/devmaster/data/** directory. If the device database is generated, the deployment is successful. + + ```shell + # ll /run/devmaster/data/ + ``` diff --git a/docs/en/devmaster_usage.md b/docs/en/devmaster_usage.md new file mode 100644 index 0000000000000000000000000000000000000000..ac3fc1cf5be0cd8a5a267010a56edb651ffb3ecd --- /dev/null +++ b/docs/en/devmaster_usage.md @@ -0,0 +1,254 @@ +# Usage Instructions + +This section describes how to use devmaster, covering daemon configuration, client tool, rule usage, and NIC configuration. + +## Daemon Configuration + +After being started, the devmaster daemon reads the configuration file, adjusts the log level, and sets the rule path based on the configuration file. devmaster has a unique configuration file **/etc/devmaster/config.toml**, which is in TOML format. + +### Configuration Items + +The devmaster configuration file supports the following configuration items: + +- **rules_d**: Rule path. The default value is **\["/etc/devmaster/rules.d"]**. If this item is not specified, there is no default path. Currently, devmaster does not support rule loading priorities. Rule files with the same name in different rule paths will not conflict with each other. Rule files are loaded in the sequence specified by **rules_d**. Rule files in the same directory are loaded in the lexicographical sequence. +- **max_workers**: Maximum number of concurrent worker threads. If this item is not specified, the default value **3** is used. +- **log_level**: Log level. The value can be **debug** or **info**. If this parameter is not specified, the default value **info** is used. +- **network_d**: NIC configuration path. The default value is **\["/etc/devmaster/network.d"]**. If this parameter is not specified, there is no default path. NIC configurations control the behavior of the `net_setup_link` command of devmaster. For details, see [NIC Configuration](#nic-configuration). + +## Client Tool + +`devctl` is the client tool of the devmaster daemon. It is used to control devmaster behaviors, simulate device events, and debug rules. + + ```shell + # devctl --help + devmaster 0.5.0 + parse program arguments + + USAGE: + devctl + + OPTIONS: + -h, --help Print help information + -V, --version Print version information + + SUBCOMMANDS: + monitor Monitor device events from kernel and userspace + kill Kill all devmaster workers + test Send a fake device to devmaster + trigger Trigger a fake device action, then the kernel will report an uevent + test-builtin Test builtin command on a device + help Print this message or the help of the given subcommand(s) + ``` + +Command options: + + `-h, --help`: Displays help information. + + `-V, --version`: Displays version information. + + ``: Subcommand to be executed, including `monitor`, `trigger`, and `test-builtin`. + +The following sections describe the three frequently used subcommands, which are used to monitor device events, trigger device events, and test built-in commands. + +### Monitoring Device Events + +Monitor uevent events reported by the kernel and events sent after devmaster processes devices, which are prefixed with **KERNEL** and **USERSPACE**, respectively. The command is as follows: + + ```shell + # devctl monitor [OPTIONS] + ``` + +Command options: + + `-h, --help`: Displays help information. + +### Triggering Device Events + +Simulate a device action to trigger a kernel uevent event. This operation is used to replay coldplug device events during kernel initialization. The command is as follows: + + ```shell + # devctl trigger [OPTIONS] [DEVICES...] + ``` + +Command options: + + `-h, --help`: Displays help information. + + `-a, --action `: Action type of a device event. + + `-t, --type `: Type of the device to be searched for. The value can be **devices** or **subsystems**. + + `-v, --verbose`: Prints the found devices. + + `-n, --dry-run`: Does not trigger device events. This option can be used together with `--verbose` to view the list of devices in the system. + + `[DEVICES...]`: Devices for which events are triggered. If this item is left blank, events of all devices in the system are triggered. + +### Testing Built-in Commands + +Test the effect of a built-in command on a device. The command is as follows: + + ```shell + # devctl test-builtin [OPTIONS] + ``` + +Command options: + + `-a, --action `: Action type of a device event. The value can be **add**, **change**, **remove**, **move**, **online**, **offline**, **bind**, or **unbind**. + + `-h, --help`: Displays help information. + + ``: Built-in command to be executed. The value can be **blkid**, **input_id**, **kmod**, **net_id**, **net_setup_link**, **path_id**, or **usb_id**. + + ``: Sysfs path of the device. + +## Rule Usage + +devmaster rules consist of a group of rule files. After the devmaster daemon is started, it loads the rule files in lexicographic order based on the rule path specified in the configuration file. + +> ![Note](./public_sys-resources/icon-note.gif)**Note:** +> +> After adding, deleting, or modifying a rule, you need to restart devmaster for the rule to take effect. + +### Rule Examples + +The following describes several common rule examples. For details about the rule syntax, see the [devmaster manual](http://sysmaster.online/man/exts/devmaster/devmaster/). + +#### Example 1: Creating a Soft Link for a Block Device + +Use the `blkid` built-in command to read the UUID of a block device and create a soft link for the block device based on the UUID. + +After an event of a device that has a file system is triggered, a soft link corresponding to the device is generated in the **/dev/test** directory. + +The following uses the block device of the **sda1** partition as an example. + +1. Create the rule file **/etc/devmaster/rules.d/00-persist-storage.rules**. The file content is as follows: + + ```shell + SUBSYSTEM!="block", GOTO="end" + + IMPORT{builtin}=="blkid" + + ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="test/$env{ID_FS_UUID_ENC}" + + LABEL="end" + ``` + +2. Trigger the **sda1** device event: + + ```shell + # devctl trigger /dev/sda1 + ``` + +3. Check if a soft link pointing to **sda1** exists in the **/dev/test/** directory. If yes, the rule takes effect. + + ```shell + # ll /dev/test/ + total 0 + lrwxrwxrwx 1 root root 7 Sep 6 15:35 06771fe1-39da-42d7-ad3c-236a10d08a7d -> ../sda1 + ``` + +#### Example 2: Renaming a NIC + +Use the `net_id` built-in command to obtain the hardware attributes of the NIC, then run the `net_setup_link` built-in command to select a hardware attribute based on the NIC configuration as the NIC name, and rename the NIC through the **NAME** rule. + +The following uses the **ens33** NIC as an example to test the effect of the NIC renaming rule: + +1. Create the rule file **/etc/devmaster/rules.d/01-netif-rename.rules**. The file content is as follows: + + ```shell + SUBSYSTEM!="net", GOTO="end" + + IMPORT{builtin}=="net_id" + + IMPORT{builtin}=="net_setup_link" + + ENV{ID_NET_NAME}=="?*", NAME="$env{ID_NET_NAME}" + + LABEL="end" + ``` + +2. Create the NIC configuration file **/etc/devmaster/network.d/99-default.link**. The content is as follows: + + ```shell + [Match] + OriginalName = "*" + + [Link] + NamePolicy = ["database", "onboard", "slot", "path"] + ``` + +3. Bring the NIC offline. + + ```shell + # ip link set ens33 down + ``` + +4. Temporarily name the NIC **tmp**: + + ```shell + # ip link set ens33 name tmp + ``` + +5. Trigger the **add** event of the NIC. + + ```shell + # devctl trigger /sys/class/net/tmp --action add + ``` + +6. Check the NIC name. If the NIC name is changed to **ens33**, the rule takes effect. + + ```shell + # ll /sys/class/net/| grep ens33 + lrwxrwxrwx 1 root root 0 Sep 6 11:57 ens33 -> ../../devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33 + ``` + +7. Restore the network connection after activating the NIC. + + ```shell + # ip link set ens33 up + ``` + +> ![Note](./public_sys-resources/icon-note.gif)**Note:** +> +> An activated NIC cannot be renamed. You need to bring it offline first. In addition, the renaming rule of devmaster takes effect only in the **add** event of the NIC. +> + +#### Example 3: Modifying the User Permissions on a Device Node + +The **OPTIONS+="static_node=\** rule enables devmaster to immediately apply the user permissions in this rule to **/dev/\** after devmaster is started. The configuration takes effect immediately after devmaster is restarted. No device event is required. + +1. Create the rule file **/etc/devmaster/rules.d/02-devnode-privilege.rules**. The file content is as follows: + + ```shell + OWNER="root", GROUP="root", MODE="777", OPTIONS+="static_node=tty5" + ``` + +2. After devmaster is restarted, check the user, user group, and permissions of **/dev/tty5**. If the user, user group, and permissions are changed to **root**, **root**, and **rwxrwxrwx**, the rule takes effect. + + ```shell + # ll /dev/tty5 + crwxrwxrwx 1 root root 4, 5 Feb 3 2978748 /dev/tty5 + ``` + +## NIC Configuration + +The NIC renaming function of devmaster is implemented by the built-in commands `net_id` and `net_setup_link` and the NIC configuration file. In the rule file, use `net_id` to obtain the hardware attributes of a NIC, and then use `net_setup_link` to select a NIC attribute as the new NIC name. The `net_setup_link` command controls the NIC naming style for a specific NIC based on the NIC configuration file. This section describes how to use the NIC configuration file. For details about how to rename a NIC, see [Renaming a NIC](#example-2-renaming-a-nic). + +### Default NIC Configurations + +devmaster provides the following default NIC configurations: + + ```toml + [Match] + OriginalName = "*" + + [Link] + NamePolicy = ["onboard", "slot", "path"] + ``` + +The NIC configuration file contains the **\[Match]** matching section and **\[Link]** control section. Each section contains several configuration items. The configuration items in the **\[Match]** section are used to match NICs. When a NIC meets all matching conditions, all configuration items in the **\[Link]** section are applied to the NIC, for example, setting the NIC naming style and adjusting NIC parameters. + +The preceding default NIC configuration indicates that the configuration takes effect on all NICs and checks the NIC naming styles of the **onboard**, **slot**, and **path** styles in sequence. If an available style is found, the NIC is named in this style. + +For details about the NIC configuration, see the [devmaster manual](http://sysmaster.online/man/exts/devmaster/netif_config/#1). diff --git a/docs/en/figures/devmaster_architecture.png b/docs/en/figures/devmaster_architecture.png new file mode 100644 index 0000000000000000000000000000000000000000..c3f0e4570d84f5ed513e0a02e0759cc3e4fb3db0 Binary files /dev/null and b/docs/en/figures/devmaster_architecture.png differ diff --git a/docs/en/figures/sysMaster.png b/docs/en/figures/sysMaster.png new file mode 100644 index 0000000000000000000000000000000000000000..85f901da2ddc33059c29df1c86b9023516921dbd Binary files /dev/null and b/docs/en/figures/sysMaster.png differ diff --git a/docs/en/overview.md b/docs/en/overview.md new file mode 100644 index 0000000000000000000000000000000000000000..5fe40cb647b35329a96d0777cd8f53323b2548dd --- /dev/null +++ b/docs/en/overview.md @@ -0,0 +1,28 @@ +# sysMaster User Guide + +## Overview + +sysMaster is a collection of ultra-lightweight and highly reliable service management programs. It provides an innovative implementation of PID 1 to replace the conventional init process. Written in Rust, sysMaster is equipped with fault monitoring, second-level self-recovery, and quick startup capabilities, which help improve OS reliability and service availability. + +sysMaster supports unified management of processes, containers, and VMs and applies to multiple scenarios such as servers, cloud computing, and embedded systems. + +sysMaster divides the functions of traditional PID 1 into a 1+1+N architecture based on application scenarios. + +As shown in the figure, sysMaster consists of three components: + +- sysmaster-init, which is a new implementation of PID 1, features simplified functions, a thousand lines of code (KLOC), and ultimate reliability. It is applicable to embedded systems with functions such as system initialization, zombie process recycling, and keep-alive monitoring. +- sysmaster-core undertakes the core service management functions and incorporates the reliability framework to enable live updates and quick self-recovery in the event of crashes, ensuring 24/7 service availability. +- sysmaster-exts offers a set of components (such as devMaster for device management and busMaster for bus communication) that deliver key system functions, which are coupled in traditional PID 1. Users can choose the components to use as required. + +**Figure 1** sysMaster architecture + +![sysMaster](./figures/sysMaster.png) + +**sysmaster** and **devmaster** are the two main packages of sysMaster, which are responsible for service management and device management, respectively. + +## Intended Audience + +This document is intended for openEuler users who need to manage services and devices. The users are expected to: + +- Know basic Linux operations. +- Know service configuration and devices. diff --git a/docs/en/service_management.md b/docs/en/service_management.md new file mode 100644 index 0000000000000000000000000000000000000000..617ec7d9562ad9ad154009671c245ef242a85aaa --- /dev/null +++ b/docs/en/service_management.md @@ -0,0 +1,5 @@ +# Service Management + +Many background programs and processes in Linux, such as web servers, database servers, and mail servers, are started and stopped during system startup and running. sysmaster provides efficient service management commands and configurations to ensure the normal running of the system. + +This document describes the installation and deployment of sysmaster, as well as its features and usage. diff --git a/docs/en/sysmaster_install_deploy.md b/docs/en/sysmaster_install_deploy.md new file mode 100644 index 0000000000000000000000000000000000000000..91a82913e8715b0188791abefe261d30dee1bc98 --- /dev/null +++ b/docs/en/sysmaster_install_deploy.md @@ -0,0 +1,98 @@ +# Installation and Deployment + +sysmaster can be used in containers and VMs. This document uses the AArch64 architecture as an example to describe how to install and deploy sysmaster in both scenarios. + +## Software + +* OS: openEuler 23.09 + +## Hardware + +* x86_64 or AArch64 architecture + +## Installation and Deployment in Containers + +1. Install Docker. + + ```bash + yum install -y docker + systemctl restart docker + ``` + +2. Load the base container image. + + Download the container image. + + ```bash + wget https://repo.openeuler.org/openEuler-23.09/docker_img/aarch64/openEuler-docker.aarch64.tar.xz + xz -d openEuler-docker.aarch64.tar.xz + ``` + + Load the container image. + + ```bash + docker load --input openEuler-docker.aarch64.tar + ``` + +3. Build the container. + + Create a Dockerfile. + + ```bash + cat << EOF > Dockerfile + FROM openeuler-23.09 + RUN yum install -y sysmaster + CMD ["/usr/lib/sysmaster/init"] + EOF + ``` + + Build the container. + + ```bash + docker build -t openeuler-23.09:latest . + ``` + +4. Start and enter the container. + + Start the container. + + ```bash + docker run -itd --privileged openeuler-23.09:latest + ``` + + Obtain the container ID. + + ```bash + docker ps + ``` + + Use the container ID to enter the container. + + ```bash + docker exec -it /bin/bash + ``` + +## Installation and Deployment in VMs + +1. Create an initramfs image. + To avoid the impact of systemd in the initrd phase, you need to create an initramfs image with systemd removed and use this image to enter the initrd procedure. Run the following command: + + ```bash + dracut -f --omit "systemd systemd-initrd systemd-networkd dracut-systemd" /boot/initrd_withoutsd.img + ``` + +2. Add a boot item. + Add a boot item to **grub.cfg**, whose path is **/boot/efi/EFI/openEuler/grub.cfg** in the AArch64 architecture and **/boot/grub2/grub.cfg** in the x86_64 architecture. Back up the original configurations and modify the configurations as follows: + + * **menuentry**: Change **openEuler (6.4.0-5.0.0.13.oe23.09.aarch64) 23.09** to **openEuler 23.09 withoutsd**. + * **linux**: Change **root=/dev/mapper/openeuler-root ro** to **root=/dev/mapper/openeuler-root rw**. + * **linux**: If Plymouth is installed, add **plymouth.enable=0** to disable it. + * **linux**: Add **init=/usr/lib/sysmaster/init**. + * **initrd**: Set to **/initrd_withoutsd.img**. +3. Install sysmaster. + + ```bash + yum install sysmaster + ``` + +4. If the **openEuler 23.09 withoutsd** boot item is displayed after the restart, the configuration is successful. Select **openEuler 23.09 withoutsd** to log in to the VM. diff --git a/docs/en/sysmaster_usage.md b/docs/en/sysmaster_usage.md new file mode 100644 index 0000000000000000000000000000000000000000..d0ae28310f5d39c1cb5eb17227aa47cb792652b7 --- /dev/null +++ b/docs/en/sysmaster_usage.md @@ -0,0 +1,104 @@ +# sysmaster Usage Instructions + +This section provides examples on how to use sysmaster, including: + +* service unit configuration file creation +* unit service management operations, such as starting, stopping, and viewing services + +For more, see the [sysMaster official manual](http://sysmaster.online/man/all/). + +## Unit Configuration File Creation + +You can create unit configuration files in the **/usr/lib/sysmaster/system/** directory. + +### Types of Unit Configuration Files + +Currently, sysmaster supports unit configuration files of the **target**, **socket**, and **service** types. + +* **target**: Encapsulated startup target managed by sysmaster, which is used for grouping units as a synchronization point. sysmaster provides targets for different states. For example, **multi-user.target** indicates that the system has been started. You can use this target to configure services to run in this state. +* **socket**: Encapsulated socket for inter-process communication to support socket-based startup. For example, you can configure a service unit to depend on a socket. When data is written to the socket, sysmaster starts the corresponding service unit. +* **service**: Encapsulated process monitored and controlled by sysmaster. + +### Composition of Unit Configuration Files + +A unit configuration file consists of three sections: + +* **Unit**: common configuration description of the unit, such as the service name, description, and dependencies +* **Install**: description of how the service is installed and started +* **Service** and **Socket**: configurations of different unit types + +### Creating a service Unit + +The **sshd** service is used to remotely log in to the server and run commands and perform operations on the remote terminal. +The following configuration items are used to create an **sshd.service** service unit: + +```bash +[Unit] +Description="OpenSSH server daemon" +Documentation="man:sshd(8) man:sshd_config(5)" +After="sshd-keygen.target" +Wants="sshd-keygen.target" + +[Service] +Type="notify" +EnvironmentFile="-/etc/sysconfig/sshd" +ExecStart="/usr/sbin/sshd -D $OPTIONS" +ExecReload="/bin/kill -HUP $MAINPID" +KillMode="process" +Restart="on-failure" +RestartSec=42 + +[Install] +WantedBy="multi-user.target" +``` + +The configuration items in the example are described as follows: + +* **Description**: Main functions of the unit. +* **Documentation**: Document link of the unit. +* **After**: Unit startup sequence. In the example, **sshd.service** is started after **sshd-keygen.target**. +* **Wants**: Dependency on another unit. In the example, **sshd-keygen.target** is automatically started with **sshd.service**. +* **Type**: How sysmaster starts the service. **notify** indicates that a notification will be sent after the main process is started. +* **EnvironmentFile**: Path of file that stores environment variables to be loaded. +* **ExecStart**: Command executed when the service is started. In the example, `sshd` is executed when **sshd.service** is started. +* **ExecReload**: Command executed to reload the **sshd.service** configurations. +* **KillMode**: How the process is killed when the service process needs to be stopped. **process** indicates that only the main process is killed. +* **Restart**: Whether to restart the service when the service exits or stops in different situations. **on-failure** indicates that the service is restarted when the service exits abnormally. +* **RestartSec**: Amount of time to wait before the service is restarted after the service exits. +* **WantedBy**: Units that depend on **sshd.service**. + +## Unit Service Management + +`sctl` is a CLI tool of sysmaster. It is used to check and control the behavior of the sysmaster server and the status of each service. It can start, stop, restart, and check system services. + +### Starting a Service + +Run the following command to start the **sshd** service and run the commands specified by **ExecStart**: + +```bash +# sctl start sshd.service +``` + +### Stopping a Service + +Run the following command to stop the **sshd** service and kill the process started by **ExecStart**: + +```bash +# sctl stop sshd.service +``` + +### Restarting a Service + +Run the following command to restart the **sshd** service. After the command is executed, the **sshd** service is stopped and then started. + +```bash +# sctl restart sshd.service +``` + +### Checking Service Status + +Run the following command to check the status of the **sshd** service. You can check whether the service is running properly by viewing the service status. + +```bash +# sctl status sshd.service +``` diff --git a/docs/zh/_toc.yaml b/docs/zh/_toc.yaml new file mode 100644 index 0000000000000000000000000000000000000000..1d11a2e0371b80e538208a69dce53cca4b10214d --- /dev/null +++ b/docs/zh/_toc.yaml @@ -0,0 +1,20 @@ +label: sysMaster用户指南 +isManual: true +description: 使用 sysMaster 管理服务器和设备 +sections: + - label: 概述 + href: ./overview.md + - label: 服务管理 + href: ./service_management.md + sections: + - label: 安装与部署 + href: ./sysmaster_install_deploy.md + - label: 使用说明 + href: ./sysmaster_usage.md + - label: 设备管理 + href: ./device_management.md + sections: + - label: 安装与部署 + href: ./devmaster_install_deploy.md + - label: 使用说明 + href: ./devmaster_usage.md diff --git a/docs/zh/device_management.md b/docs/zh/device_management.md new file mode 100644 index 0000000000000000000000000000000000000000..9fa6b496e474b31d090c5ff35a0679fa072b6e93 --- /dev/null +++ b/docs/zh/device_management.md @@ -0,0 +1,14 @@ +# 设备管理 + +设备管理器作为链接用户态软件与底层物理设备的桥梁,支撑着 `lvm2`、`NetworkManager`等关键基础软件的运作。`devmaster`作为 `sysMaster`的设备管理组件,一方面支撑 `sysMaster`的快速启动以及用户态软件的生态兼容,另一方面通过对 `Linux`生态下主流设备管理方案的现状和优劣进行了总结和思考,从而提供一种分层解耦、可扩展性强、面向通用 `OS`的设备管理能力。 + +`devmaster`由常驻进程、客户端工具和动态库组成。常驻进程`devmaster`基于内核提供的`netlink`、`inotify`、`sysfs`等机制,监听设备事件并触发规则处理任务;客户端工具`devctl`和动态库`libs`提供一组命令行指令以及公开接口,用于调试规则、控制常驻进程、查询设备状态等等。`devmaster`的总体架构如下图所示: + +**图1 devMaster的总体架构** +![devMaster的总体架构](./figures/devmaster_architecture.png) + +`devmaster`使用 `Rust`语言编写,能够原生消除内存安全类问题。`devmaster`的核心功能如下: + +1. 事件驱动:利用队列缓存和 `worker`池机制,满足设备事件高并发的场景,并支持将设备就绪状态动态地通知到用户态进程。 +2. 机制与策略分离:将设备处理逻辑定义在规则中,避免业务硬编码,提供按需定制、灵活组合的能力。 +3. 生态兼容:良好地兼容 `udev`语法和 `udev`用户态广播协议,支持原有业务低成本迁移到 `devmaster`环境。 diff --git a/docs/zh/devmaster_install_deploy.md b/docs/zh/devmaster_install_deploy.md new file mode 100644 index 0000000000000000000000000000000000000000..29cd080c9a55eee4fb52600d7b284523e0095a83 --- /dev/null +++ b/docs/zh/devmaster_install_deploy.md @@ -0,0 +1,67 @@ +# 安装与部署 + +`devmaster`目前可应用于虚拟机环境,本章节介绍安装部署的规格约束以及操作流程。 + +## 软件要求 + +* 操作系统:`openEuler 23.09` + +## 硬件要求 + +* `x86_64`架构、`aarch64`架构 + +## 安装部署流程 + +1. 执行如下命令,使用`yum`工具安装`sysmaster-devmaster`包: + + ```shell + # yum install sysmaster-devmaster + ``` + +2. 执行如下命令,创建默认规则文件`/etc/devmaster/rules.d/99-default.rules`和常驻进程的配置文件`/etc/devmaster/config.toml`: + + ```shell + # mkdir -p /etc/devmaster/rules.d + # mkdir -p /etc/devmaster/network.d + # echo "TAG+=\"devmaster\"" > /etc/devmaster/rules.d/99-default.rules + # cat << EOF > /etc/devmaster/config.toml + log_level = "info" + rules_d = ["/etc/devmaster/rules.d"] + network_d = ["/etc/devmaster/network.d"] + max_workers = 1 + log_targets = ["console"] + EOF + ``` + +3. 执行如下命令启动常驻进程`devmaster`,并将日志导出到`/tmp/devmaster.log`文件中: + + ```shell + # /lib/devmaster/devmaster &>> /tmp/devmaster.log & + ``` + + > [!NOTE]说明 + > `devmaster`需要以 `root`权限启动,并且不能和 `udev`同时处于运行状态,启动 `devmaster`前需要停止`udev`服务。 + + 要停止`udev`服务,`sysmaster`启动环境下,执行以下命令: + + ```shell + # sctl stop udevd.service udevd-control.socket udevd-kernel.socket + ``` + + 要停止`udev`服务,`systemd`启动环境下,执行以下命令: + + ```shell + # systemctl stop systemd-udevd.service systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket + ``` + +4. 执行如下命令,使用 `devctl`工具触发设备事件: + + ```shell + # devctl trigger + ``` + +5. 查看 `/run/devmaster/data/`目录,如果生成设备数据库,则表示部署成功: + + ```shell + # ll /run/devmaster/data/ + ``` diff --git a/docs/zh/devmaster_usage.md b/docs/zh/devmaster_usage.md new file mode 100644 index 0000000000000000000000000000000000000000..38b96356aa7cda7957eff2d2b58d0aba07148d5f --- /dev/null +++ b/docs/zh/devmaster_usage.md @@ -0,0 +1,251 @@ +# 使用说明 + +本章介绍 `devmaster`的使用方法,包括常驻进程配置、客户端工具、规则使用说明和网卡配置。 + +## 常驻进程配置 + +常驻进程 `devmaster`启动后会读取配置文件,并根据配置文件内容,调整日志级别、设置规则加载路径等等。`devmaster`拥有唯一的配置文件,路径为 `/etc/devmaster/config.toml`,文件内容采用 `toml`格式。 + +### 配置选项 + +目前 `devmaster`配置文件中支持的配置选项如下: + +- `rules_d`: 指定规则加载路径,默认规则中设置为 `["/etc/devmaster/rules.d"]`,未指定时无默认加载路径。`devmaster`当前不支持规则加载优先级,不同规则路径下的同名规则文件不会发生覆盖。规则文件的加载顺序按照 `rules_d`配置项中指定的目录顺序,相同目录下按照规则文件的字典序进行加载。 +- `max_workers`: 指定最大 `worker`线程并发数,未指定时默认为3。 +- `log_level`: 指定日志级别,支持 `debug`和 `info`级别,未指定时默认为 `"info"`。 +- `network_d`: 指定网卡配置加载路径,默认规则中设置为 `["/etc/devmaster/network.d"]`,未指定时无默认加载路径。网卡配置用于控制 `devmaster`的内置命令 `net_setup_link`的行为,具体可参考[网卡配置说明](#网卡配置)。 + +## 客户端工具 + +`devctl`是常驻进程 `devmaster`的客户端工具,用来控制 `devmaster`的行为、模拟设备事件、调试规则等等。 + + ```shell + # devctl --help + devmaster 0.5.0 + parse program arguments + + USAGE: + devctl + + OPTIONS: + -h, --help Print help information + -V, --version Print version information + + SUBCOMMANDS: + monitor Monitor device events from kernel and userspace + kill Kill all devmaster workers + test Send a fake device to devmaster + trigger Trigger a fake device action, then the kernel will report an uevent + test-builtin Test builtin command on a device + help Print this message or the help of the given subcommand(s) + ``` + +选项说明: + + `-h, --help`: 显示帮助信息。 + + `-V, --version`: 显示版本信息。 + + ``: 选择执行的子命令,包括`monitor`、`trigger`、`test-builtin`等。 + +接下来介绍三种常用的子命令,分别用于监听设备事件、触发设备事件以及测试内置命令。 + +### 监听设备事件 + +监听内核上报的 `uevent`事件和 `devmaster`处理完设备后发出的事件,分别以 `KERNEL`和 `USERSPACE`作为前缀进行区分,执行的命令如下: + + ```shell + # devctl monitor [OPTIONS] + ``` + +选项说明: + + `-h, --help`: 显示帮助信息。 + +### 触发设备事件 + +模拟一个设备动作,使内核上报对应的uevent事件,用于重放内核初始化过程中的冷插(coldplug)设备事件,执行的命令如下: + + ```shell + # devctl trigger [OPTIONS] [DEVICES...] + ``` + +选项说明: + + `-h, --help`: 显示帮助信息。 + + `-a, --action `: 指定设备事件的动作类型。 + + `-t, --type `: 指定搜索的设备类型,可以是`devices`(设备)或者`subsystems`(子系统)。 + + `-v, --verbose`: 打印搜索到的设备。 + + `-n, --dry-run`: 不会实际触发设备事件,配合`--verbose`选项使用时,可以查看系统中的设备清单。 + + `[DEVICES...]`: 指定若干个需要触发事件的设备,如果为空,则触发系统中所有设备的事件。 + +### 测试内置命令 + +测试内置命令在某个设备上的执行效果,执行的命令如下: + + ```shell + # devctl test-builtin [OPTIONS] + ``` + +选项说明: + + `-a, --action `: 指定设备事件的动作类型,包括:`add`、`change`、`remove`、`move`、`online`、`offline`、`bind`和 `unbind`。 + + `-h, --help`: 显示帮助信息。 + + ``: 选择执行的内置命令,目前支持`blkid`、`input_id`、`kmod`、`net_id`、`net_setup_link`、`path_id`、`usb_id`。 + + ``: 指定设备的 `sysfs`路径。 + +## 规则使用说明 + +`devmaster`的规则由一组规则文件组成,`devmaster`常驻进程启动后会根据配置文件中指定的规则加载目录,按字典序依次加载各个规则文件。 + +> [!NOTE]说明 +> 增加、删除、修改规则后,均需要重启 `devmaster`使之生效。 + +### 常用规则案例 + +以下介绍几种常见的规则应用案例,规则语法详见官方文档中的[devmaster手册](http://sysmaster.online/man/exts/devmaster/devmaster/)。 + +#### 示例1: 创建块设备软链接 + +通过 `blkid`内置命令,读取块设备的 `uuid`,并基于 `uuid`创建块设备的软链接。 + +触发拥有文件系统的某块设备的事件后,在 `/dev/test`目录下生成该设备对应的软链接。 + +以 `sda1`分区块设备为例,测试规则效果: + +1. 创建规则文件 `/etc/devmaster/rules.d/00-persist-storage.rules`,内容如下: + + ```shell + SUBSYSTEM!="block", GOTO="end" + + IMPORT{builtin}=="blkid" + + ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="test/$env{ID_FS_UUID_ENC}" + + LABEL="end" + ``` + +2. 触发 `sda1`设备的事件: + + ```shell + # devctl trigger /dev/sda1 + ``` + +3. 查看 `/dev/test/`目录下存在指向 `sda1`的软链接,表示规则生效: + + ```shell + # ll /dev/test/ + total 0 + lrwxrwxrwx 1 root root 7 Sep 6 15:35 06771fe1-39da-42d7-ad3c-236a10d08a7d -> ../sda1 + ``` + +#### 示例2: 网卡重命名 + +使用 `net_id`内置命令,获取网卡设备的硬件属性,再使用 `net_setup_link`内置命令,基于网卡配置选择某个硬件属性作为网卡名,最后通过 `NAME`规则重命名网卡。 + +以 `ens33`网卡为例,测试网卡重命名规则的效果: + +1. 创建规则文件 `/etc/devmaster/rules.d/01-netif-rename.rules`,内容如下: + + ```shell + SUBSYSTEM!="net", GOTO="end" + + IMPORT{builtin}=="net_id" + + IMPORT{builtin}=="net_setup_link" + + ENV{ID_NET_NAME}=="?*", NAME="$env{ID_NET_NAME}" + + LABEL="end" + ``` + +2. 创建网卡配置`/etc/devmaster/network.d/99-default.link`,内容如下: + + ```shell + [Match] + OriginalName = "*" + + [Link] + NamePolicy = ["database", "onboard", "slot", "path"] + ``` + +3. 先将网卡设备下线: + + ```shell + # ip link set ens33 down + ``` + +4. 将网卡名临时命名为 `tmp`: + + ```shell + # ip link set ens33 name tmp + ``` + +5. 触发网卡设备的 `add`事件: + + ```shell + # devctl trigger /sys/class/net/tmp --action add + ``` + +6. 查看网卡名称,发现重新命名为 `ens33`,表示规则生效: + + ```shell + # ll /sys/class/net/| grep ens33 + lrwxrwxrwx 1 root root 0 Sep 6 11:57 ens33 -> ../../devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33 + ``` + +7. 激活网卡后恢复网络连接: + + ```shell + # ip link set ens33 up + ``` + +> [!NOTE]说明 +> 网卡设备处于激活状态下无法重命名,需要先将其下线。另外 `devmaster`仅在网卡设备的 `add`事件下对网卡重命名才会生效。 + +#### 示例3: 修改设备节点的用户权限 + +`OPTIONS+="static_node=`规则会使 `devmaster`启动后,立即将本规则行中的用户权限应用在 `/dev/`设备节点上。重启 `devmaster`后立即生效,无需设备事件触发。 + +1. 创建规则文件`/etc/devmaster/rules.d/02-devnode-privilege.rules`,内容如下: + + ```shell + OWNER="root", GROUP="root", MODE="777", OPTIONS+="static_node=tty5" + ``` + +2. 重启 `devmaster`后,观察 `/dev/tty5`的用户、用户组和权限,变更为 `root`、`root`和 `rwxrwxrwx`,表示规则生效: + + ```shell + # ll /dev/tty5 + crwxrwxrwx 1 root root 4, 5 Feb 3 2978748 /dev/tty5 + ``` + +## 网卡配置 + +`devmaster`的网卡重命名功能由内置命令 `net_id`、`net_setup_link`和网卡配置文件配合完成。在规则文件中,通过 `net_id`获取网卡的硬件属性,再使用 `net_setup_link`选择某个网卡属性作为新的网卡名。`net_setup_link`命令基于网卡配置,针对特定网卡设备,控制网卡命名的风格。本章主要介绍网卡配置文件的使用方法,网卡重命名的实施方法可参考[网卡重命名规则案例](#示例2-网卡重命名)。 + +### 默认网卡配置 + +`devmaster`提供了如下默认网卡配置: + + ```toml + [Match] + OriginalName = "*" + + [Link] + NamePolicy = ["onboard", "slot", "path"] + ``` + +网卡配置文件中包含 `[Match]`匹配节和 `[Link]`控制节,每节中包含若干配置项。匹配节的配置项用于匹配网卡设备,当网卡满足所有匹配条件时,将控制节中的所有配置项作用在网卡上,比如设置网卡名选取策略、调整网卡参数等等。 + +以上列举的默认网卡配置表示将该配置作用在所有网卡设备上,并依次检查 `onboard`、`slot`和 `path`风格的网卡命名风格,如果找到一个可用的风格,就以该风格对网卡进行命名。 + +网卡配置的详细说明可以参考 `sysMaster`官方手册中的[devmaster手册](http://sysmaster.online/man/exts/devmaster/netif_config/#1)。 diff --git a/docs/zh/figures/devmaster_architecture.png b/docs/zh/figures/devmaster_architecture.png new file mode 100644 index 0000000000000000000000000000000000000000..c60c9505c570093c78fa5335b590e7da58c7cc7c Binary files /dev/null and b/docs/zh/figures/devmaster_architecture.png differ diff --git a/docs/zh/figures/sysMaster.png b/docs/zh/figures/sysMaster.png new file mode 100644 index 0000000000000000000000000000000000000000..5f4a8d239727c4d22f2b8841946bb12cd4a8d86b Binary files /dev/null and b/docs/zh/figures/sysMaster.png differ diff --git a/docs/zh/overview.md b/docs/zh/overview.md new file mode 100644 index 0000000000000000000000000000000000000000..4dabdafd410bed2b1f815baef677a2e498e3b5e5 --- /dev/null +++ b/docs/zh/overview.md @@ -0,0 +1,27 @@ +# sysMaster用户指南 + +## 概述 + +`sysMaster`是一套超轻量、高可靠的服务管理程序集合,是对 `1`号进程的全新实现,旨在改进传统的 `init`守护进程。它使用 `Rust`编写,具有故障监测、秒级自愈和快速启动等能力,从而提升操作系统可靠性和业务可用度。 + +`sysMaster`支持进程、容器和虚拟机的统一管理,其适用于服务器、云计算和嵌入式等多个场景。 + +`sysMaster`实现思路是将传统 `1`号进程的功能解耦分层,结合使用场景,拆分出 `1+1+N`的架构。 + +如下面 `sysMaster`系统架构图所示,主要包含三个方面: +• `sysmaster-init`:新的 `1`号进程提供系统初始化、僵尸进程回收、监控保活等功能,可单独应用于嵌入式场景。 +• `sysmaster-core`:承担原有服务管理的核心功能,引入可靠性框架,使其具备崩溃快速自愈、热升级等能力,保障业务全天在线。 +• `sysmaster-exts`:使原本耦合的各组件功能独立,提供系统关键功能的组件集合(如设备管理 `devMaster`,总线通信 `busMaster`等),各组件可单独使用,可根据不同场景灵活选用。 + +**图1** sysMaster整体架构图 + +![sysMaster](./figures/sysMaster.png) + +`sysMaster`目前主要由 `sysmaster`和 `devmaster`2部分功能组成,其中 `sysmaster`负责服务的管理,`devmaster`负责设备的管理,下面将对这2部分功能进行说明。 + +## 读者对象 + +本文档主要适用于使用 `openEuler`并需要对服务和设备进行管理的用户。用户需要具备以下经验和技能: + +* 熟悉 `Linux`基本操作 +* 对服务配置和设备有一定了解 diff --git a/docs/zh/service_management.md b/docs/zh/service_management.md new file mode 100644 index 0000000000000000000000000000000000000000..ba8dedd4f178a8048eba05d6d0234c17f76f3fd2 --- /dev/null +++ b/docs/zh/service_management.md @@ -0,0 +1,5 @@ +# 服务管理 + +在 `Linux`中,有很多在后台运行的程序或进程,如 `Web`服务器、数据库服务器、邮件服务器等。系统启动和运行过程中会启动和停止这些程序。 `sysmaster`对此提供了高效的服务管理的命令及配置,确保系统正常工作。 + +本文主要介绍 `sysmaster`的安装部署与各个特性说明和使用方法,使用户能够快速了解并使用。 diff --git a/docs/zh/sysmaster_install_deploy.md b/docs/zh/sysmaster_install_deploy.md new file mode 100644 index 0000000000000000000000000000000000000000..19acc7673fc287af4ca341eabd88a0fe809da256 --- /dev/null +++ b/docs/zh/sysmaster_install_deploy.md @@ -0,0 +1,100 @@ +# 安装与部署 + +`sysmaster`可应用于容器和虚拟机,本文档将以 `aarch64`系统为例说明如何在各场景下进行安装与部署。 + +## 软件要求 + +* 操作系统:`openEuler 23.09` + +## 硬件要求 + +* `x86_64`架构、`aarch64`架构 + +## 容器场景安装与部署 + +1. 安装 docker + + ```bash + yum install -y docker + systemctl restart docker + ``` + +2. 加载基础容器镜像 + + 下载容器镜像 + + ```bash + wget https://repo.openeuler.org/openEuler-23.09/docker_img/aarch64/openEuler-docker.aarch64.tar.xz + xz -d openEuler-docker.aarch64.tar.xz + ``` + + 加载容器镜像 + + ```bash + docker load --input openEuler-docker.aarch64.tar + ``` + +3. 构建容器 + + 创建 Dockerfile + + ```bash + cat << EOF > Dockerfile + FROM openeuler-23.09 + RUN yum install -y sysmaster + CMD ["/usr/lib/sysmaster/init"] + EOF + ``` + + 构建容器 + + ```bash + docker build -t openeuler-23.09:latest . + ``` + +4. 启动并进入容器 + + 启动容器 + + ```bash + docker run -itd --privileged openeuler-23.09:latest + ``` + + 获取`CONTAINERID` + + ```bash + docker ps + ``` + + 使用上一步获取到`CONTAINERID`进入容器 + + ```bash + docker exec -it CONTAINERID /bin/bash + ``` + +## 虚拟机场景安装与部署 + +1. `initramfs`镜像制作 + 为了避免 `initrd`阶段 `systemd`的影响,需要制作一个剔除 `systemd`的 `initramfs`镜像,并以该镜像进入 `initrd`流程。使用如下命令: + + ```bash + dracut -f --omit "systemd systemd-initrd systemd-networkd dracut-systemd" /boot/initrd_withoutsd.img + ``` + +2. 新增启动项 + + 在 `grub.cfg`中增加新的启动项,`aarch64`下的路径为 `/boot/efi/EFI/openEuler/grub.cfg`,`x86_64`下的路径为 `/boot/grub2/grub.cfg`,拷贝一份原有启动项,并做以下几处修改: + + * `menuentry` 项修改启动项名称 `openEuler (6.4.0-5.0.0.13.oe23.09.aarch64) 23.09`为 `openEuler 23.09 withoutsd` + * `linux` 项内核启动参数修改 `root=/dev/mapper/openeuler-root ro` 为 `root=/dev/mapper/openeuler-root rw` + * `linux` 项内核启动参数修改 `plymouth`,如果环境上安装了 `plymouth`, 需要添加 `plymouth.enable=0` 禁用 `plymouth` + * `linux` 项内核启动参数增加 `init=/usr/lib/sysmaster/init` + * `initrd` 项修改为 `/initrd_withoutsd.img` + +3. 安装 sysmaster + + ```bash + yum install sysmaster + ``` + +4. 重启后出现 `openEuler 23.09 withoutsd`启动项表示已成功配置,选择此启动项进入虚拟机 diff --git a/docs/zh/sysmaster_usage.md b/docs/zh/sysmaster_usage.md new file mode 100644 index 0000000000000000000000000000000000000000..506a5cc8def9343076e5ae70e00665b7dbf51273 --- /dev/null +++ b/docs/zh/sysmaster_usage.md @@ -0,0 +1,102 @@ +# sysmaster使用说明 + +本章主要通过一些实例来带领用户初步使用 `sysmaster`,例如: + +* 如何创建 `service`服务单元配置文件。 +* 如何管理单元服务,例如启动、停止、查看服务。 + +## 创建单元配置文件 + +用户可以在 `/usr/lib/sysmaster/system/`目录下创建单元配置文件。 + +### 单元配置文件的类型 + +当前 `sysmaster`支持 `target`、`socket`、`service`类型的单元配置文件。 + +* `target`:封装了一个由 `sysmaster`管理的启动目标,用于将多个单元集中到一个同步点。`sysmaster`提供不同阶段的 `target`单元,例如 `multi-user.target`代表系统已完成启动,用户可以依赖此目标,启动自己的服务。 +* `socket`:封装了一个用于进程间通信的套接字 `socket`, 以支持基于套接字的启动。例如用户可以配置 `service`单元依赖此 `socket`,当此 `socket`有数据写入时,`sysmaster`会拉起对应的 `service`单元。 +* `service`:封装了一个被 `sysmaster`监视与控制的进程。 + +### 单元配置文件的构成 + +单元配置文件通常由3块组成: + +* `Unit`:单元的公共配置说明,如服务名称、描述、依赖关系等。 +* `Install`:描述如何安装和启动服务。 +* `Service`、`Socket`:各个单元类型的配置。 + +### 创建service单元配置 + +`sshd`服务被用来远程登录到服务器,并在远程终端上执行命令和操作。 +使用如下配置项来创建一个 `sshd.service`服务单元配置。 + +```bash +[Unit] +Description="OpenSSH server daemon" +Documentation="man:sshd(8) man:sshd_config(5)" +After="sshd-keygen.target" +Wants="sshd-keygen.target" + +[Service] +Type="notify" +EnvironmentFile="-/etc/sysconfig/sshd" +ExecStart="/usr/sbin/sshd -D $OPTIONS" +ExecReload="/bin/kill -HUP $MAINPID" +KillMode="process" +Restart="on-failure" +RestartSec=42 + +[Install] +WantedBy="multi-user.target" +``` + +以下是对单元配置文件中选项配置的说明,更多可以查阅[官方手册](https://openeuler-sysmaster.github.io/sysmaster/index_zh/)。 + +* `Description`:说明该 `unit`的主要功能。 +* `Documentation`:说明该 `unit`的文档链接。 +* `After`:配置同时启动的单元的先后顺序,`sshd.service`服务将在 `sshd-keygen.target`之后启动。 +* `Wants`:配置一个单元对另一个单元的依赖,启动 `sshd.service`服务,将会自动启动 `sshd-keygen.target`。 +* `Type`:配置 `sysmaster` 如何启动此服务,`notify`表明需要主进程启动完成后发送通知消息。 +* `EnvironmentFile`:设置环境变量的文件读取路径。 +* `ExecStart`:配置服务启动时执行的命令,启动 `sshd.service`服务会执行 `sshd`命令。 +* `ExecReload`:配置重新加载 `sshd.service`的配置时执行的命令。 +* `KillMode`:配置当需要停止服务进程时,杀死服务进程的方法,`process`表示只杀死主进程。 +* `Restart`:配置服务不同情况下退出或终止,是否重新启动服务,`on-failure`表示当服务非正常退出时重新启动服务。 +* `RestartSec`:配置当服务退出时,重新拉起服务的间隔时间。 +* `WantedBy`:配置依赖当前 `sshd.service`服务的单元。 + +## 管理单元服务 + +`sctl`是 `sysmaster`的命令行工具,用于检查和控制 `sysmaster`服务端行为和各个服务的状态,它可以启动、停止、重启、检查系统服务。 + +### 启动服务 + +使用以下命令可以启动 `sshd`服务和运行 `ExecStart`所配置的命令。 + +```bash +sctl start sshd.service +``` + +### 停止服务 + +使用以下命令可以停止 `sshd`服务,杀死 `ExecStart`所运行的进程。 + +```bash +sctl stop sshd.service +``` + +### 重启服务 + +使用以下命令可以重启 `sshd`服务,该命令会先停止后启动服务。 + +```bash +sctl restart sshd.service +``` + +### 查看服务状态 + +使用以下命令可以查看服务 `sshd`运行状态,用户可以查看服务的状态来获取服务是否正常运行。 + +```bash +sctl status sshd.service +```