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 启动前就去连，报连接拒绝。
