错误。systemd服务文件不应强制设置Restart=always和Type=simple；Type需据进程行为选择（前台用simple，后台daemon用forking），Restart应优先用on-failure而非always，且必须配RestartSec避免触发速率限制。
systemd服务文件必须设置Restart=always和Type=simple
Python脚本默认以普通进程启动，Type=forking会误判进程生命周期，导致systemd无法正确监控。用Type=simple告诉systemd：主进程就是你启动的python进程本身；配合Restart=always才能在崩溃、退出、被kill时自动拉起。
常见错误是写成Type=oneshot（只执行一次）或漏掉RestartSec=5——没有这个，重启会立刻发生，可能触发systemd的频率限制而进入failed状态。
-
Restart=always：无论退出码是什么都重启（包括0） -
RestartSec=5：每次重启前等待5秒，避免高频失败循环 -
StartLimitInterval=60和StartLimitBurst=3建议显式配置，防止1分钟内连续失败3次后被systemd永久禁用
Python脚本需避免前台阻塞失效或日志丢失
systemd要求服务进程必须“前台运行”——不能后台化（如nohup python app.py &），否则systemd会认为启动失败。同时，print输出默认带缓冲，若脚本崩溃前没刷出日志，journalctl -u your-service里就看不到最后几行。
- 启动命令写成
ExecStart=/usr/bin/python3 -u /opt/myapp/app.py，-u启用无缓冲模式 - 不要在脚本里调用
os.system("nohup ... &")或subprocess.Popen(..., daemon=True) - 如果用
asyncio.run()或flask.run()等长期运行逻辑，确保它们不被try/except SystemExit意外吞掉退出信号
权限与路径问题常导致启动失败但无明显报错
systemd默认以root运行，但你的Python依赖可能装在用户目录（如~/.local/lib），或脚本用了相对路径读配置文件，一开机就找不到config.yaml。此时journalctl -u your-service里往往只显示Process exited with code 1，不报具体异常。
基础设计系统架构——涵盖令牌层级、主题基础架构、令牌流水线及治理规范。适用于创建设计令牌、实现主题切换、配置 Style Dictionary 或建立多品牌主题。在设计令牌、主题提供者、Style Dictionary、令牌流水线、多品牌主题及 CSS 自定义属性架构时触发。
立即学习“Python免费学习笔记（深入）”；
- 用绝对路径：所有
ExecStart、WorkingDirectory、配置文件路径都写全，比如WorkingDirectory=/opt/myapp - 确认Python环境：别依赖
python软链，明确写/usr/bin/python3.10或用venv路径，如/opt/myapp/venv/bin/python - 若需非root权限，加
User=www-data和Group=www-data，并确保该用户对代码目录有读+执行权
调试时别只看service状态，要盯journalctl实时输出
systemctl status your-service只显示摘要，真正崩溃原因藏在日志流里。尤其当Python抛出ImportError或PermissionError时，systemd不会翻译，只会记下退出码。
- 启动后立刻执行
journalctl -u your-service -f，观察首行是否打印“Started …”，再看是否有ModuleNotFoundError或Address already in use - 改完服务文件必须
sudo systemctl daemon-reload，否则systemctl restart仍用旧配置 - 测试崩溃恢复：手动
kill -9 $(pgrep -f "app.py")，等5秒看是否重新出现进程（pgrep -f app.py）
最易忽略的是工作目录和Python路径的隐式依赖——本地能跑，放进systemd就ModuleNotFoundError，八成是WorkingDirectory没设或设错了。动手前先用sudo -u root /usr/bin/python3 -u /opt/myapp/app.py模拟systemd环境跑一遍。
