使用systemd采用.service文件方式启动的应用程序在后台执行

本文链接：https://blog.youkuaiyun.com/qq_33471732/article/details/144906168

当使用systemd通过.service文件启动应用程序时，应用程序默认没有与传统意义上的终端直接关联。

标准输入输出（STDIN/STDOUT/STDERR）

默认行为：systemd启动的服务，其标准输入（STDIN）默认是关闭的，标准输出（STDOUT）和标准错误输出（STDERR）会被捕获并记录到systemd的日志中。可以通过 journalctl -u <service_name> 命令查看服务的输出日志，其中 <service_name> 是你的.service文件中定义的服务名称。
重定向配置：如果希望将服务的输出发送到文件，可以在.service文件中使用 StandardOutput 和 StandardError 选项进行配置。例如：

[Service]
ExecStart=/path/to/your/application
StandardOutput=file:/var/log/your_service.log
StandardError=inherit

在上述配置中，StandardOutput=file:/var/log/your_service.log 将标准输出重定向到 /var/log/your_service.log 文件，StandardError=inherit 表示标准错误输出将跟随标准输出的设置，也输出到该文件。

控制终端概念

无控制终端：与在终端中交互式启动的进程不同，systemd启动的服务没有控制终端（controlling terminal）。这意味着诸如 Ctrl + C （发送 SIGINT 信号）、Ctrl + Z （发送 SIGTSTP 信号）等依赖控制终端的操作对服务进程无效。systemd使用自己的机制来管理服务的启动、停止和重启，例如 systemctl start <service_name> 、systemctl stop <service_name> 和 systemctl restart <service_name> 。
模拟终端交互（特殊情况）：在某些特定场景下，如果服务需要类似终端交互的环境，可以通过配置 TTYPath 等选项在.service文件中模拟。但这种情况相对较少，且需要谨慎配置，因为systemd服务通常设计为在后台无交互地运行。例如：

[Service]
ExecStart=/path/to/your/interactive/application
TTYPath=/dev/tty1

上述配置尝试将服务关联到 /dev/tty1 设备，以模拟某种程度的终端交互环境，但并非所有应用程序都能适应这种设置，且可能需要额外的权限和配置。

那可能你会想这不就是守护进程吗？

虽然systemd启动的应用程序在很多方面表现得像守护进程，但不能简单地认为它们就是守护进程。以下是两者的联系与区别：

联系

后台运行特性：守护进程的主要特点之一是在后台运行，脱离控制终端，不与用户直接交互。systemd启动的应用程序默认也在后台运行，不依赖于特定的终端，这与守护进程的运行方式相似。例如，常见的网络服务如 httpd （Apache Web服务器），既可以作为守护进程运行，当通过systemd管理时，同样在后台运行，为用户提供服务而无需终端交互。
系统服务管理：守护进程通常是为系统提供某种持续性服务的进程，systemd启动的应用程序大多也是用于提供系统服务，如文件服务、数据库服务等。systemd对这些应用程序的管理方式，包括启动、停止、重启、监控等，与传统守护进程的管理需求是一致的。

区别

实现方式：
- 传统守护进程：传统守护进程需要通过编写特定的代码逻辑来实现守护进程化。这通常涉及创建子进程、父进程退出、创建新的会话（setsid）、更改工作目录、重设文件权限掩码以及关闭不必要的文件描述符等步骤，以确保进程完全脱离终端环境并在后台稳定运行。例如，下面是一个简单的C语言实现守护进程的示例代码片段：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main() {
    pid_t pid, sid;

    // 创建子进程
    pid = fork();
    if (pid < 0) {
        perror("fork");
        exit(EXIT_FAILURE);
    } else if (pid > 0) {
        // 父进程退出
        exit(EXIT_SUCCESS);
    }

    // 创建新的会话
    sid = setsid();
    if (sid < 0) {
        perror("setsid");
        exit(EXIT_FAILURE);
    }

    // 更改工作目录
    if ((chdir("/")) < 0) {
        perror("chdir");
        exit(EXIT_FAILURE);
    }

    // 重设文件权限掩码
    umask(0);

    // 关闭标准输入、输出和错误输出
    close(STDIN_FILENO);
    close(STDOUT_FILENO);
    close(STDERR_FILENO);

    // 主循环
    while (1) {
        // 执行守护进程的任务
        sleep(1);
    }

    return 0;
}

- **systemd启动的应用程序**：使用systemd启动的应用程序，无需在应用程序代码中实现上述复杂的守护进程化步骤。systemd负责在启动应用程序时，将其以一种类似守护进程的方式运行。应用程序开发者只需要关注应用程序本身的功能实现，而systemd负责处理进程的后台运行、资源管理等相关事宜。例如，一个简单的Python脚本，原本不是按照守护进程方式编写的，通过systemd配置后，也能以类似守护进程的方式运行。假设 `test.py` 脚本内容为：

import time
while True:
    print('Running...')
    time.sleep(1)

在对应的 .service 文件中配置：

[Unit]
Description=My Python Service
After=network.target

[Service]
ExecStart=/usr/bin/python3 /path/to/test.py

[Install]
WantedBy=multi - user.target

通过 systemctl start my_service 启动后，该Python脚本就像守护进程一样在后台持续运行。
2. 生命周期管理：
- 传统守护进程：传统守护进程通常需要自己实现复杂的生命周期管理逻辑，包括如何优雅地处理启动、停止、重启信号，以及如何在异常情况下进行自我修复或通知系统管理工具。例如，守护进程可能需要捕获 SIGTERM 信号来实现优雅关闭，在接收到信号后，清理资源、关闭文件描述符等，然后再退出。
- systemd启动的应用程序：systemd提供了统一且强大的生命周期管理机制。通过 systemctl 命令，管理员可以方便地对服务进行启动、停止、重启、状态查看等操作。systemd还能自动处理服务的依赖关系，例如在启动某个服务前，确保其依赖的其他服务已经启动。此外，systemd可以监控服务的运行状态，当服务异常退出时，根据配置决定是否自动重启服务。例如，通过在 .service 文件的 [Service] 部分添加 Restart=always 配置，当服务意外终止时，systemd会自动将其重启。