systemd服务启动后手动执行frankenphp serve报“Address already in use”，是因为systemd已占用端口（如:80），手动运行必然冲突；应停用systemd服务（sudo systemctl stop frankenphp）后再手动启动，避免双实例共存导致socket残留、日志混杂及资源浪费。
systemd服务启动后手动执行frankenphp serve会报Address already in use
这是因为 systemd 已经拉起了一个 FrankenPHP 实例（比如监听 :80 或 :8080），你再手动运行 frankenphp serve，端口必然冲突。错误信息通常是 listen tcp :80: bind: address already in use，不是配置错，是系统级资源被占。
解决思路很简单：别共存。生产环境只用 systemd 管理；调试时先停掉服务再手动启。
-
确认服务是否在运行：
systemctl is-active frankenphp，返回active就说明已在跑 -
临时停服务：
sudo systemctl stop frankenphp，停完再手动运行frankenphp serve即可 -
别用
sudo systemctl restart frankenphp后立刻手动启：restart 不保证旧进程完全退出，尤其有残留 worker 时，建议 stop → wait 2 秒 → 再 start 或手动启 -
检查是否有残留进程：
ps aux | grep -i frankenphp，若看到多个frankenphp或php进程且 CMD 含serve，用kill -15 PID清理
手动改了配置但systemd服务不生效
常见于直接编辑了 /etc/frankenphp/config.yaml 或项目根目录的 frankenphp.yaml，但 systemctl restart frankenphp 后没变化——根本原因是 systemd service 文件里可能硬编码了启动参数，覆盖了配置文件。
查 systemd 启动命令最准的方式是：systemctl cat frankenphp.service，重点看 ExecStart= 行。
立即学习“PHP免费学习笔记（深入）”；
使用 Kadence 主题作为 WordPress 项目的设计系统，涵盖设计令牌、布局系统、页头/页脚/导航设置以及页面/归档/单篇文章模板。
- 如果它写的是
ExecStart=/usr/bin/frankenphp serve --addr :80 --config /path/to/override.yaml，那你改默认配置文件没用，得改它指定的那个路径 - 如果它没带
--config，但用了--script或--env，这些参数会优先于配置文件里的同名项 - 修改 service 文件后必须执行：
sudo systemctl daemon-reload，否则restart不加载新定义 - 改完建议用
sudo systemctl show --property=ExecStart frankenphp验证最终生效的命令
日志里出现两个frankenphp进程，一个来自systemd一个来自cron或shell脚本
典型症状是 journalctl -u frankenphp 里混着不同时间戳、不同工作目录、甚至不同用户（root vs www-data）的日志行。这说明有人在 crontab、部署脚本或 CI 流水线里写了 frankenphp serve & 这类后台命令，绕过了 systemd。
这种“双实例”不仅浪费资源，还可能导致 socket 文件冲突、缓存状态不一致、甚至数据库连接池耗尽。
- 搜全系统自动任务：
grep -r "frankenphp.*serve" /etc/cron* /var/spool/cron 2>/dev/null - 检查常用部署脚本位置：
/opt/deploy.sh、/home/deploy/run.sh、.git/hooks/post-merge - 确认所有非 systemd 启动方式都删掉或注释掉，统一收口到
systemctl start frankenphp - 如果必须保留某脚本触发重启，让它调用
sudo systemctl reload-or-restart frankenphp，而不是自己拉进程
systemd服务启停慢，疑似和手动进程卡死有关
执行 sudo systemctl stop frankenphp 卡住几十秒，或者 status 显示 deactivating (stop-sigterm) 长时间不退，大概率是 FrankenPHP 进程没收到或没响应 SIGTERM —— 特别是当你之前手动启过、又忘了关，导致 systemd 管理的进程和手动进程共享了同一个 socket 文件（如 /tmp/frankenphp.sock）或监听地址。
关键点在于：FrankenPHP 的 graceful shutdown 依赖信号处理，而手动启动时若没加 --graceful-timeout 或用了 & 脱离终端，容易变成孤儿进程。
- 强制清理 socket 文件：
sudo rm -f /tmp/frankenphp.sock（路径以你的配置为准） - 杀掉所有疑似残留：
sudo pkill -f "frankenphp.*serve\|frankenphp.*worker"，注意转义空格 - 在 service 文件中显式加超时和信号配置：
[Service] Type=simple KillSignal=SIGTERM TimeoutStopSec=10 Restart=on-failure
- 避免手动启动时后台化：
frankenphp serve就保持前台运行；真要后台请用systemd-run --scope临时托管
真正麻烦的不是端口冲突本身，而是多个启动入口混用后留下的状态残影——socket 文件、共享内存段、未释放的数据库连接，这些不会随 systemctl stop 自动清理，得靠人盯住。
