答案是创建systemd单元文件以管理服务。首先编写.service文件定义服务的启动、用户权限、日志输出等行为，将其置于/etc/systemd/system/目录，使用systemctl命令加载、启动并启用开机自启；通过systemctl status和journalctl -u排查启动失败问题，检查ExecStart路径、权限、用户存在性及依赖关系；安全实践包括使用非特权用户、限制文件系统访问、网络、资源和能力，遵循最小权限原则，提升服务隔离性与系统安全性。
在Linux中编写服务，尤其是在现代发行版中，核心就是创建并配置一个systemd单元文件。这个文件本质上告诉systemd你的程序如何启动、停止、重启，以及在系统启动时如何管理它。它提供了一种标准化且强大的方式来定义系统进程的行为。
解决方案
编写一个systemd单元文件来定义你的服务，通常是一个
.service
文件。这个文件会告诉systemd你的应用程序如何运行，以及它与其他系统组件的关系。我们以一个简单的Python脚本为例，这个脚本会持续输出当前时间到日志中。
首先，假设你有一个名为
my_script.py
的Python脚本，内容如下：
#!/usr/bin/env python3import timeimport datetimeimport sysdef run_service(): while True: timestamp = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S") print(f"[{timestamp}] My service is running...", file=sys.stderr) # Output to stderr so journalctl captures it easily sys.stderr.flush() time.sleep(5)if __name__ == "__main__": run_service()
将这个脚本保存到
/opt/my-service/my_script.py
，并确保它有执行权限：
sudo mkdir -p /opt/my-service
sudo mv my_script.py /opt/my-service/
sudo chmod +x /opt/my-service/my_script.py
接下来，你需要创建一个systemd单元文件。通常，这些文件放在
/etc/systemd/system/
目录下。我们将创建
my-awesome-app.service
。
# /etc/systemd/system/my-awesome-app.service[Unit]Description=My Awesome Python ServiceAfter=network.target # 确保网络服务启动后才尝试启动此服务[Service]ExecStart=/usr/bin/python3 /opt/my-service/my_script.py # 你的服务启动命令，请使用绝对路径WorkingDirectory=/opt/my-service/ # 服务运行的工作目录User=nobody # 推荐使用非特权用户运行服务，例如nobody或专门创建的用户Group=nogroup # 同上Restart=on-failure # 当服务失败时（例如程序退出码非0），systemd会自动重启它StandardOutput=journal # 将标准输出重定向到journald日志系统StandardError=journal # 将标准错误重定向到journald日志系统[Install]WantedBy=multi-user.target # 表示此服务应该在多用户模式下被启动
文件内容解析：
[Unit]
部分定义了服务的通用信息和依赖关系。
Description
: 服务的描述，方便人类阅读。
After=network.target
: 这是一个常见的依赖设置，表示你的服务应该在
network.target
（代表网络服务已准备就绪）之后启动。这只是一个顺序指示，不代表强依赖。
[Service]
部分是核心，定义了如何运行你的服务。
ExecStart
: 这是启动服务的实际命令。务必使用绝对路径，因为systemd运行环境的
PATH
可能与你的shell环境不同。这里我们直接调用Python解释器来运行脚本。
WorkingDirectory
: 指定服务的工作目录。如果你的服务需要访问相对路径的文件，这个设置就很重要。
User
和
Group
: 出于安全考虑，强烈建议使用非特权用户（如
nobody
或为你服务专门创建的用户）和组来运行服务，而不是
root
。
Restart=on-failure
: 这是一个非常实用的指令。如果你的服务进程意外退出（例如，脚本抛出未捕获的异常），systemd会自动尝试重启它。
always
会无条件重启，
no
则不重启。
StandardOutput
和
StandardError
: 将服务的标准输出和标准错误流重定向到
journald
日志系统，这样你就可以通过
journalctl
命令来查看服务的日志了。
[Install]
部分定义了服务如何被“启用”（enabled），即在系统启动时自动运行。
WantedBy=multi-user.target
: 这表示当系统进入多用户运行级别时（大多数服务器的默认运行级别），你的服务应该被启动。
启用和管理服务：
重新加载systemd配置： 每当你修改或添加了单元文件，都需要告诉systemd重新加载配置。
sudo systemctl daemon-reload
启动你的服务：
sudo systemctl start my-awesome-app.service
检查服务状态：
sudo systemctl status my-awesome-app.service
你会看到服务的运行状态，包括是否正在运行、最近的日志输出等。设置服务开机自启：
sudo systemctl enable my-awesome-app.service
这会在
/etc/systemd/system/multi-user.target.wants/
目录下创建一个符号链接到你的单元文件，确保系统启动时自动运行。停止服务：
sudo systemctl stop my-awesome-app.service
禁用服务（取消开机自启）：
sudo systemctl disable my-awesome-app.service
通过这种方式，你的应用程序就变成了一个由systemd管理、具有良好行为的系统服务。
如何调试一个无法启动的systemd服务？
当一个systemd服务拒绝启动时，那种挫败感确实让人头疼。我记得有一次，我花了好几个小时才发现只是
ExecStart
路径写错了。所以，调试的关键在于系统性地排查。
立即检查服务状态：
systemctl status
这是你的第一站。它会显示服务的当前状态、进程ID、内存占用，以及最近几行日志。通常，错误信息（比如“Failed to start…”）和一些关键的日志行会在这里显示出来，用红色高亮。仔细阅读这些信息，它们往往能直接指出问题所在。
深入查看日志：
journalctl -u -e
如果
systemctl status
给出的信息不够详细，
journalctl
是你的最佳拍档。
journalctl -u
：显示该服务的所有日志。
journalctl -u -e
：显示最新的日志条目，通常包括错误信息。
journalctl -u -f
：实时跟踪日志输出，当你尝试启动服务时，可以立即看到产生的任何错误。很多时候，服务的实际错误（比如程序自身的异常、配置加载失败）都会通过标准输出或标准错误流被journald捕获。
验证单元文件语法：
systemd-analyze verify
虽然systemd通常会报告语法错误，但提前检查总是个好习惯。这个命令可以帮助你发现单元文件中的一些基本语法问题。例如：
systemd-analyze verify /etc/systemd/system/my-awesome-app.service
。
检查
ExecStart
命令和权限：
知网AI智能写作
知网AI智能写作，写文档、写报告如此简单
38 查看详情 绝对路径： 确保
ExecStart
中使用的所有命令和脚本都使用了绝对路径。Systemd运行环境的
PATH
变量可能非常有限，不像你在shell中那么丰富。执行权限： 你的脚本或二进制文件是否有执行权限？例如，对于shell或Python脚本，你需要
chmod +x /path/to/your/script.sh
。用户/组权限： 如果你指定了
User=
和
Group=
，请确保该用户和组存在，并且它们对
ExecStart
指定的程序、
WorkingDirectory
以及任何需要访问的文件/目录都有足够的读写权限。尝试手动以该用户身份运行
ExecStart
命令，看看是否会报错：
sudo -u /path/to/your/command
。
检查依赖关系：
After=
和
Requires=
如果你的服务依赖于其他服务（比如
network.target
或数据库服务），确保这些依赖的服务本身正在运行并且健康。
Requires=
是强依赖，如果依赖服务启动失败，你的服务也不会启动。
After=
只是排序，即使依赖服务失败，你的服务也可能尝试启动。
环境和工作目录：
Environment=
和
WorkingDirectory=
服务是否需要特定的环境变量？确保它们在
[Service]
部分的
Environment=
指令中设置了。
WorkingDirectory
是否正确？如果你的服务需要加载相对路径的配置文件，那么工作目录的设置至关重要。
手动运行服务命令：最直接的调试方法之一是，复制
ExecStart
中的命令，然后在shell中手动运行它，最好是切换到
User=
指令指定的用户身份下运行。
sudo -u bash -c "/path/to/your/command --with-args"
这可以帮助你隔离问题：是单元文件配置问题，还是程序自身的问题。
记住，调试是一个迭代的过程。每次修改后，都要
sudo systemctl daemon-reload
，然后再次尝试启动并检查状态和日志。
编写systemd服务时，有哪些安全性最佳实践？
安全性在任何服务部署中都是至关重要的，systemd提供了很多机制来帮助你沙箱化你的服务，限制其潜在的破坏力。我个人觉得，这些安全配置一开始看起来有点多余，但一旦你遇到过权限滥用导致的问题，就会觉得它们是多么宝贵。
最小权限原则（Principle of Least Privilege）：
User=
和
Group=
： 这是最重要的。永远不要以
root
用户运行你的服务，除非绝对必要。 为每个服务创建一个专用的非特权用户和组。例如，如果你的服务叫
my-app
，就创建
my-app
用户和
my-app
组，并让服务以这个身份运行。这样，即使服务被攻破，攻击者也只能获得这个非特权用户的权限，大大限制了损害范围。示例：
User=my-appGroup=my-app
限制文件系统访问：Systemd允许你精细地控制服务可以访问的文件系统区域。
ReadOnlyPaths=
/
ReadWritePaths=
/
InaccessiblePaths=
： 明确指定服务可以读/写或完全不能访问的路径。这可以防止服务意外或恶意地修改关键系统文件。
ReadOnlyPaths=/etc/my-app/config
ReadWritePaths=/var/log/my-app /var/lib/my-app
InaccessiblePaths=/home /srv
ProtectSystem=full
或
strict
： 将大部分系统目录挂载为只读。
full
会保护
/usr
、
/boot
等，
strict
还会保护
/etc
。通常，
full
是一个不错的起点。
ProtectHome=true
： 防止服务访问用户的主目录（
/home
和
/root
）。
PrivateTmp=true
： 为服务提供一个独立的、私有的
/tmp
和
/var/tmp
目录。这样，服务就不会看到或干扰其他进程的临时文件，也无法利用全局临时文件进行攻击。
限制网络访问：
RestrictAddressFamilies=AF_UNIX AF_INET
： 限制服务可以使用的网络协议族。例如，如果你的服务只需要本地套接字和IPv4网络，可以这样设置。
IPAddressAllow=
/
IPAddressDeny=
： 虽然防火墙是更推荐的网络过滤方式，但这些指令可以在单元文件层面提供额外的控制，限制服务可以连接的IP地址。
资源限制：防止服务耗尽系统资源，影响其他服务或导致系统不稳定。
MemoryLimit=
： 限制服务可以使用的内存量（例如
500M
）。
CPUShares=
： 分配CPU时间片，相对于其他服务。
LimitNOFILE=
： 限制服务可以打开的文件描述符数量。
LimitNPROC=
： 限制服务可以创建的进程/线程数量。
能力（Capabilities）限制：Linux Capabilities允许将root用户的特权细分为更小的、独立的单元。
CapabilityBoundingSet=
： 明确指定服务可以拥有的Linux Capabilities。默认情况下，服务会继承一些Capabilities。通过清空或只指定必要的Capabilities，可以大大减少服务的特权。例如，如果服务不需要绑定特权端口，就可以移除
CAP_NET_BIND_SERVICE
。
NoNewPrivileges=true
： 这是一个非常重要的安全特性，它阻止服务通过
setuid
/
setgid
程序或其他方式获取新的特权。
PrivateDevices=true
：阻止服务访问
/dev
目录下的设备节点，除非明确允许。这可以防止服务与硬件直接交互。
一个更安全的
[Service]
部分示例：
[Service]ExecStart=/usr/bin/python3 /opt/my-service/my_script.pyWorkingDirectory=/opt/my-service/User=my-appGroup=my-app# 文件系统隔离ProtectSystem=fullProtectHome=true
以上就是如何在Linux中编写服务 Linux systemd单元文件的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/436085.html
微信扫一扫 
支付宝扫一扫 
