systemd服务文件必须放在/etc/systemd/system/（首选）或/lib/systemd/system/（仅系统自带），execstart须用绝对路径并显式指定user，修改后必须执行sudo systemctl daemon-reload才能生效。
systemd服务文件必须放对位置
自Ubuntu 15.04起，systemd是唯一被官方支持的服务管理机制，所有新部署的服务都应走这条路。但很多人卡在第一步：把.service文件放错目录导致systemctl enable失败或启动报Unit not found。
正确路径只有两个：
-
/etc/systemd/system/—— 用户自定义服务的**首选且唯一推荐位置**，优先级最高，不会被系统更新覆盖 -
/lib/systemd/system/—— 仅存放系统自带服务（如ssh.service），手动写入此处可能被包管理器清理或冲突
常见错误：把服务文件丢进/usr/lib/systemd/system/或~/下再用绝对路径启动——systemctl根本不会扫描这些路径。
ExecStart路径和权限必须显式指定
写完.service文件后，systemctl start myapp报Failed to start: Permission denied或No such file or directory，90%是因为ExecStart没写全路径或用户权限不对。
关键点：
-
ExecStart值必须是**绝对路径**，不能用~或$HOME（systemd不展开shell变量） -
User=必须明确指定，否则默认以root运行，而你的Python脚本可能依赖普通用户家目录下的配置或虚拟环境 - 如果脚本依赖
venv，务必写成：ExecStart=/home/user/myenv/bin/python /home/user/app.py，而不是只写python app.py
漏掉User或用错路径，进程会启动失败但systemctl status只显示exited, code=203/EXEC，这个错误码专指执行权限或路径问题。
Restart策略和日志查看要配对使用
很多服务看似启动成功，但几秒后就退出，systemctl status只显示Active: inactive (dead)，却找不到原因——因为默认不记录标准输出/错误，也没启用自动重启。
Ubuntu 26.04 LTS（代号“Resolute Raccoon”）是Canonical于2026年4月23日发布的下一代长期支持版操作系统，提供长达10年的技术支持。它搭载Linux 7.0内核与GNOME 50桌面环境，全面转向Wayland协议，并引入Rust重写的核心工具以增强安全性。官方提供适用于AMD64和ARM64架构的桌面及服务器ISO镜像，是追求前沿技术与极致稳定的开发者
基础加固配置：
-
Restart=on-failure：仅在非0退出码时重启（适合大多数应用） -
RestartSec=5：失败后等5秒再重启，避免快速失败循环 -
StandardOutput=journal和StandardError=journal：确保所有输出进journald，之后可用journalctl -u myapp.service -f实时跟踪
别依赖stdout_logfile这类Supervisor风格配置——systemd原生不认，硬写进去会被忽略。
启用前必须重载配置并检查语法
改完.service文件后直接systemctl enable，常遇到Failed to enable unit: Unit file myapp.service does not exist，其实是配置没生效。
必须按顺序执行三步：
-
sudo systemctl daemon-reload：让systemd重新读取所有.service文件（修改后必做） -
sudo systemctl link /etc/systemd/system/myapp.service（可选）：仅当文件不在标准路径时临时链接，但不如直接放对位置 -
sudo systemctl daemon-validate myapp.service：检查语法是否合法（Ubuntu 22.04+支持），能提前发现Missing required key类错误
跳过daemon-reload就enable或start，systemd永远看不到你新加的文件。
真正麻烦的不是写服务文件，而是systemd把“启动成功”和“进程存活”拆成了两层判断——它只管进程是否被fork出来，不管里面跑的是不是你想要的逻辑。所以Status=active (running)只是假象，得靠journalctl和Restart策略兜底。
