workerman服务不能直接用nohup启动实现可靠自启,因nohup不管理进程生命周期;必须使用systemd,正确配置service文件(禁用-d、设type=simple、user非root)、reload、enable后方可开机自启并自动恢复。

Workerman 服务为什么不能直接用 nohup 启动后就当自启用
因为 nohup 只是绕过终端挂起信号,不解决进程生命周期管理:系统重启后它不会自动拉起,崩溃也不会自动重启,更没法和系统日志、依赖服务(比如 Redis、MySQL)做联动。systemd 才是 Linux 发行版(尤其是 CentOS 7+/Ubuntu 16.04+)真正可靠的自启机制。
常见错误现象:systemctl start workerman 报 Failed to start workerman.service: Unit workerman.service not found —— 这说明服务文件根本没放对位置,或没重载配置。
- 服务文件必须放在
/etc/systemd/system/下,不能放错到/lib/systemd/system/(那是系统包管理器用的) - 写完文件后必须执行
sudo systemctl daemon-reload,否则 systemd 完全看不到新服务 - Workerman 主进程默认以守护模式(
-d)运行,但 systemd 要求主进程前台运行,否则会误判为“启动失败”
怎么写一个能跑通的 workerman.service 文件
核心原则:关掉 Workerman 自己的守护,让 systemd 接管进程生命周期。关键参数是去掉 -d,加 --daemon=0(新版 Workerman)或改用 start -d=false(旧版)。
典型配置(适配大多数 Workerman 项目,如 GatewayWorker 或普通 HTTP Worker):
[Unit] Description=Workerman service After=network.target [Service] Type=simple User=www-data WorkingDirectory=/var/www/myapp ExecStart=/usr/bin/php /var/www/myapp/start.php start --daemon=0 Restart=always RestartSec=3 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target
-
Type=simple表示主进程就是 ExecStart 启动的那个,不是 fork 出来的子进程 —— Workerman 默认是 simple 类型,别乱改成forking -
Restart=always是必须的,否则 Worker 崩溃后不会自动拉起;但注意它不会在start.php本身报错退出时触发(比如 PHP 语法错误),那得靠日志排查 -
User必须设成非 root(如www-data或nginx),否则 Workerman 启动时可能因权限问题 bind 失败,报Permission denied
启动失败时怎么看日志和定位问题
别急着改配置,先看 systemd 记的真日志:sudo journalctl -u workerman -f。比 start.php 自己输出的日志更底层、更及时。
常见错误现象和对应动作:
- 日志里反复出现
PHP Fatal error: Class 'Workerman\Worker' not found→ 检查WorkingDirectory是否指向了正确的项目根目录,且vendor/autoload.php存在 - 启动后立刻退出,
systemctl status workerman显示inactive (dead)→ 很可能是start.php执行完就退出了,确认是否误用了stop或restart命令写在了ExecStart里 - 报
Address already in use→ 端口被占用,用sudo lsof -i :2345(替换为你监听的端口)查进程,别直接 kill,先stop再start - 日志空白或只有 “Started Workerman service” → 说明进程启动了但没输出,检查
start.php是否调用了Worker::runAll(),这是阻塞主循环的关键
开机自启生效前最容易漏的一步
写好 service 文件、reload、start 都成功了,不代表开机就能跑。必须显式启用:
sudo systemctl enable workerman
这个命令本质是创建软链接:/etc/systemd/system/multi-user.target.wants/workerman.service → /etc/systemd/system/workerman.service。漏掉这步,重启后服务压根不会尝试启动。
验证是否生效:sudo systemctl is-enabled workerman 应返回 enabled;再手动 reboot 测试一次,别只信理论。
另外,如果项目依赖 Redis 或 MySQL,记得在 [Unit] 里加 After=redis-server.service 或 Wants=redis-server.service,否则 Workerman 可能抢在 Redis 启动前就去连,报连接拒绝。










