Linux如何创建自定义systemd服务

答案是编写.service文件并配置重启策略、日志管理、依赖关系和权限隔离。首先创建包含[Unit]、[Service]、[Install]三部分的service文件，设置Type、ExecStart、User、Restart等关键参数；接着将文件放入/etc/systemd/system/目录，执行daemon-reload加载配置；然后通过enable设置开机自启，start启动服务；最后用status和journalctl排查问题。相比传统脚本，systemd具备并行启动、依赖管理、集中日志、资源控制和自动重启等优势，通过合理配置可确保服务稳定可靠运行。

在Linux系统上创建自定义systemd服务，本质上就是编写一个

.service

解决方案

创建自定义systemd服务通常涉及以下几个核心步骤。我个人觉得，理解每一步背后的逻辑比单纯记住命令更重要，因为这能帮助你在遇到问题时快速定位。

第一步：编写你的服务单元文件

这是最关键的一步。你需要创建一个以

.service

my-app.service

/etc/systemd/system/

一个典型的

.service

[Unit]

[Service]

[Install]

# /etc/systemd/system/my-app.service

[Unit]
Description=我的自定义应用程序服务
# 这个服务在网络准备好之后才启动，对于需要网络的应用很重要。
# 如果你的应用不需要网络，可以省略或改为其他依赖。
After=network.target

[Service]
# Type=simple 表示ExecStart定义的命令就是主进程。
# 如果你的程序会fork出子进程然后主进程退出，可能需要Type=forking。
Type=simple
# 定义服务启动时执行的命令。这里我假设你有一个Python脚本。
# 最好使用绝对路径，避免环境问题。
ExecStart=/usr/bin/python3 /opt/my-app/app.py
# 定义服务停止时执行的命令，可选。
# 如果不指定，systemd会发送SIGTERM信号。
# ExecStop=/usr/bin/pkill -f "python3 /opt/my-app/app.py"
# 服务的运行用户和组，出于安全考虑，尽量不要用root。
User=myuser
Group=myuser
# 服务的工作目录。
WorkingDirectory=/opt/my-app/
# 当服务异常退出时，systemd会尝试重启它。
# on-failure表示只有在非正常退出（如错误码非0）时才重启。
# always表示无论如何都重启。
Restart=on-failure
# 重启前等待的秒数。
RestartSec=5
# 标准输出和标准错误重定向到journald，方便日志查看。
StandardOutput=journal
StandardError=journal

[Install]
# WantedBy=multi-user.target 表示当系统进入多用户模式（正常运行级别）时，
# 这个服务会被启动。这是最常见的设置，意味着系统启动时自动运行。
WantedBy=multi-user.target

这里我用了一个Python脚本作为例子，但

ExecStart

第二步：重新加载systemd配置

在你创建或修改了

.service

sudo systemctl daemon-reload

这步非常重要，否则systemd不会找到你的新服务或应用你的修改。

第三步：启用你的服务

启用服务意味着systemd会在系统启动时自动启动它。

sudo systemctl enable my-app.service

这个命令会在

/etc/systemd/system/multi-user.target.wants/

第四步：启动你的服务

现在，你可以手动启动你的服务了：

sudo systemctl start my-app.service

第五步：检查服务状态

随时查看你的服务是否正常运行，以及最近的日志输出：

sudo systemctl status my-app.service

如果一切顺利，你会看到服务处于“active (running)”状态。

如何确保自定义systemd服务稳定可靠地运行？

让一个服务“跑起来”和让它“稳定可靠地跑起来”是两码事。我个人在部署生产环境服务时，会特别关注几个点，它们是确保服务健壮性的基石。

首先是重启策略（Restart Policy）。在

[Service]

Restart=

on-failure

RestartSec=5

RestartSec

其次是日志管理。我强烈建议将

StandardOutput

StandardError

journal

journald

journalctl -u my-app.service

再者是资源限制。对于一些资源密集型或可能失控的服务，使用

LimitNOFILE

LimitNPROC

还有依赖关系。

[Unit]

After=

Requires=

network.target

postgresql.service

最后是权限隔离。在

[Service]

User=

Group=

root

ProtectSystem=full

ProtectHome=true

通义万相

通义万相，一个不断进化的AI艺术创作大模型

596

查看详情

systemd服务与传统启动脚本相比，有哪些显著优势？

回想我刚接触Linux那会儿，都是用

rc.local

/etc/init.d/

首先，启动速度和并行化。传统的SysV init脚本是串行执行的，一个服务启动完才能轮到下一个。systemd通过其复杂的依赖关系管理，能够识别出哪些服务可以并行启动，从而大大缩短了系统的启动时间。这就像是把单车道变成了多车道高速公路。

其次，强大的依赖管理。在SysV init中，依赖关系通常通过脚本中的注释来暗示，或者需要手动调整启动顺序的数字。systemd则提供了

After=

Requires=

Wants=

再者，统一的日志管理。前面提到了

journald

/var/log/

journald

journalctl

还有，资源控制（Cgroups）集成。systemd与Linux内核的Cgroups紧密集成，这意味着你可以非常精细地控制每个服务所能使用的CPU、内存、I/O等资源。这对于防止单个服务耗尽系统资源，或者在多租户环境中进行资源隔离非常有用。这是传统init脚本很难实现的功能。

最后，服务监控与自动重启。systemd能够持续监控服务的状态，并在服务异常退出时根据配置（如

Restart=on-failure

supervisord

这些优势加起来，使得systemd在管理复杂系统服务时，无论是效率、可靠性还是易用性上，都远超传统的init系统。

自定义systemd服务遇到问题时，我应该如何进行故障排查？

哪怕是经验再丰富的开发者，在配置systemd服务时也难免会遇到一些“小插曲”。关键在于，当服务不按预期工作时，你得知道从哪里入手去“审问”它。我个人觉得，故障排查就像是侦探破案，需要一步步抽丝剥茧。

第一步，也是最直接的一步，就是检查服务状态。

sudo systemctl status my-app.service

这个命令会告诉你服务当前是运行中、失败、还是停止。更重要的是，它会显示最近的几行日志，以及服务进程的退出代码。如果状态显示

failed

第二步，深入查看日志。

如果

status

journalctl

sudo journalctl -u my-app.service

这个命令会显示该服务的所有日志。我通常会加上

-f

--since "1 hour ago"

sudo journalctl -u my-app.service -f # 实时跟踪日志
sudo journalctl -u my-app.service --since "2023-10-27 10:00:00" # 查看特定时间点后的日志

日志往往能揭示服务启动失败的具体原因，比如找不到文件、权限不足、端口被占用、程序内部错误等。

第三步，手动执行

ExecStart

很多时候，服务在systemd下启动失败，但在终端手动执行

ExecStart

WorkingDirectory

ExecStart

sudo su - myuser # 切换到服务运行的用户
cd /opt/my-app/ # 进入工作目录
/usr/bin/python3 /opt/my-app/app.py # 尝试手动运行程序

如果手动运行失败，那么问题出在程序本身或其运行环境。如果手动运行成功，但在systemd下失败，那很可能是systemd服务文件中的配置问题，比如：

• 权限问题：服务用户对程序文件、日志文件、数据目录是否有读写执行权限？
• 环境变量：服务是否依赖某些环境变量？systemd默认提供的环境变量很少，你可能需要在服务文件中用

  Environment=

  登录后复制
  或

  EnvironmentFile=

  登录后复制
  来设置。
• 工作目录：

  WorkingDirectory=

  登录后复制
  是否设置正确？程序是否依赖当前工作目录来查找资源？
• 依赖服务：

  After=

  登录后复制
  或

  Requires=

  登录后复制
  中的依赖服务是否真的已经启动并正常工作？

第四步，检查服务文件语法。

虽然不常见，但服务文件本身可能存在语法错误。你可以使用

systemd-analyze verify

systemd-analyze verify /etc/systemd/system/my-app.service

这个命令会指出服务文件中的任何语法错误或不规范之处。

通过这些步骤，你通常能够定位到问题的根源。记住，耐心和细致是故障排查的关键。

以上就是Linux如何创建自定义systemd服务的详细内容，更多请关注php中文网其它相关文章！