Workerman的命令行操作核心是通过php start.php [命令] [选项]管理服务,支持start、stop、restart、reload和status等命令,实现服务的启动、停止、重启、平滑重启与状态查看;平滑重启(reload)可在不中断连接的情况下更新代码,适合生产环境;调试时建议前台运行查看实时日志,结合status命令和日志文件排查端口占用、路径错误、扩展缺失等问题;多进程下命令作用于整个应用,无法直接操作单个Worker,但可通过系统命令kill指定PID实现局部重启,主进程会自动拉起新进程,确保服务稳定。

Workerman的命令行操作,说白了,就是通过执行你的Workerman应用主文件,然后带上一些参数来告诉它该干什么。核心逻辑非常直接:启动、停止、重启、查看状态,这些都是围绕你那个
php your_workerman_script.php命令展开的。掌握了这些基础,你就能把Workerman服务玩转起来,无论是开发调试还是生产部署,都离不开它。
解决方案
Workerman的命令行操作主要围绕着你的应用入口文件。假设你的Workerman应用入口文件是
start.php,那么所有的操作都将通过
php start.php [命令] [选项]的形式进行。
最常用的几个命令包括:
启动服务:
php start.php start
这个命令会在前台启动Workerman服务。如果你想让它在后台运行,也就是所谓的守护进程模式,就需要加上-d
参数:php start.php start -d
。我个人觉得,调试的时候在前台跑很方便,能直接看到日志输出,一旦确定没问题了,再扔到后台去。停止服务:
php start.php stop
这个会尝试优雅地停止所有Workerman进程。如果遇到僵尸进程或者服务死活停不下来,可以尝试强制停止:php start.php stop -g
。-g
参数会发送SIGKILL
信号,直接杀死进程,但这样可能会导致正在处理的请求中断,所以非必要不推荐。重启服务:
php start.php restart
顾名思义,就是先停止再启动。同样,可以带上-d
参数让它在后台重启:php start.php restart -d
。平滑重启:
php start.php reload
这是Workerman一个非常棒的特性。它会在不中断现有连接的情况下,重新加载Worker进程的代码。这对于线上更新代码非常有用,用户几乎无感知。通常,你修改了业务代码后,只需要执行php start.php reload
,Workerman就会逐步替换旧的Worker进程。查看服务状态:
php start.php status
这个命令会显示Workerman服务当前的运行状态,包括每个Worker的进程ID、内存占用、连接数、请求数等等。这是排查问题和监控服务健康状况的第一手资料。
一个简单的例子: 假设你的
start.php内容如下:
onMessage = function($connection, $data)
{
$connection->send('Hello Workerman!');
};
// 运行所有Worker
Worker::runAll();那么,你就可以这样操作:
-
启动:
php start.php start -d
-
查看状态:
php start.php status
-
修改代码后平滑重启:
php start.php reload
-
停止:
php start.php stop
Workerman服务启动后如何确保其稳定运行并实现平滑重启?
确保Workerman服务稳定运行,并能进行平滑重启,这在生产环境中是至关重要的。我个人的经验是,首先要利用好Workerman自带的守护进程模式和平滑重启机制,这是基础。
启动时务必使用守护进程模式:
php your_workerman_script.php start -d。这样服务会在后台运行,不会因为你关闭终端而停止。我见过不少新手,直接
php start.php start,然后终端一关,服务也跟着没了,这就是没理解守护进程的意义。
平滑重启是Workerman的一大亮点,它的核心在于
php your_workerman_script.php reload。当你执行这个命令时,Workerman会向所有子进程发送一个信号,通知它们在处理完当前请求后退出,然后主进程会启动新的子进程来替代它们。这个过程是渐进的,不会一下子中断所有服务,确保了用户体验。但这里有个小坑,如果你修改了
onWorkerStart这类在Worker启动时才执行的逻辑,或者一些全局配置,
reload可能无法完全生效,因为有些代码是在主进程启动时就已经加载的。所以,遇到这种情况,可能还是需要
restart一下。
另外,日志是服务稳定运行的眼睛。Workerman默认会将日志输出到
Worker::$logFile指定的文件中,如果没有指定,在守护进程模式下会输出到
/dev/null或者默认的日志文件。确保你的日志文件可写,并且定期查看日志,可以帮助你发现潜在的问题,比如内存泄漏、异常报错等。我通常会结合
tail -f your_workerman_script.log来实时监控服务状态,一旦有异常,立马就能看到。
调试Workerman应用时,命令行有哪些实用技巧或常见问题排查方法?
调试Workerman应用,命令行是你的主战场。我发现最实用的技巧就是利用前台启动模式和日志输出。
首先,前台启动:
php your_workerman_script.php start(不加
-d)。这样所有的
echo、
var_dump以及PHP的错误信息都会直接输出到你的终端,一目了然。当你代码有语法错误、逻辑问题或者想看某个变量的值时,这比去翻日志文件要快得多。我就经常在开发阶段用这种方式,快速定位问题。
本文档主要讲述的是github协同工作教程;文中将以gitchinaui项目为例进行讲解。git有命令行和图形工具,强烈推荐你用命令行工具。希望本文对大家会有帮助;感兴趣的朋友可以过来看看
其次,善用status
命令:
php your_workerman_script.php status。这个命令能告诉你每个Worker进程的PID、内存占用、连接数、请求数等。如果发现某个Worker进程的内存占用异常高,或者连接数一直不下降,那很可能就是有内存泄漏或者连接没有正确关闭。你可以根据PID去进一步排查,比如用
strace -p [PID]看它在干什么。
日志文件:Workerman的错误日志默认会输出到
Worker::$logFile指定的文件。如果没指定,在守护进程模式下,Workerman会尝试将标准输出和标准错误重定向到
/dev/null或默认日志文件。所以,确保你了解日志的去向。我习惯在
Worker::$logFile里明确指定一个路径,比如
Worker::$logFile = '/var/log/workerman/app.log';,这样所有的运行日志和错误都能集中管理。当服务出问题时,第一件事就是
tail -f /var/log/workerman/app.log,看看有没有报错信息。
常见问题排查:
-
端口被占用: 启动时报错“Address already in use”。这通常意味着你尝试监听的端口已经被其他程序占用了。你可以用
netstat -tulnp | grep [端口号]
来查找是哪个进程占用了端口,然后决定是杀死那个进程还是更换Workerman的监听端口。 -
文件路径问题: Workerman应用依赖的类库或文件找不到。检查你的
require_once
路径是否正确,vendor/autoload.php
是否加载了正确的自动加载文件。 -
PHP版本或扩展问题: Workerman对PHP版本和一些扩展(如
event
、posix
、pcntl
)有要求。如果报错说某个函数不存在,很可能是PHP缺少了必要的扩展。php -m
可以查看已安装的扩展。 -
死循环或长时间阻塞: 如果服务启动后,某个Worker进程CPU占用率一直很高,或者不响应任何请求,可能是代码里有死循环或者IO操作长时间阻塞。这时
status
命令可能会显示该Worker的请求数不再增加。在前台模式下,你可能会看到PHP的超时错误。
Workerman命令行操作中,如何处理多进程模式下的特定Worker或服务的管理?
Workerman在多进程模式下,其命令行操作通常是针对整个Workerman应用实例的。也就是说,当你执行
start、
stop、
reload这些命令时,它们会影响到你应用中的所有Worker进程,而不是某个特定的子Worker。
Workerman的设计哲学是,一个Workerman应用通常包含一个或多个
Worker实例(比如一个HTTP Worker,一个WebSocket Worker),这些实例由一个主进程管理,并派生出多个子进程来处理并发。命令行操作的粒度是这个“Workerman应用”,而不是它内部的某个子Worker进程。
举个例子,如果你定义了
$http_worker和
$websocket_worker两个Worker实例,当执行
php start.php reload时,这两个Worker实例下的所有子进程都会被平滑重启。你无法直接通过Workerman的命令行,单独去重启
$http_worker下的某个进程,而保留
$websocket_worker的进程不动。
当然,如果你有多个独立的Workerman应用(比如
app_http.php和
app_websocket.php),那么每个应用都有自己独立的命令行接口。你可以分别对它们进行启动、停止和重启操作。这其实是更常见的部署方式,将不同的服务拆分成独立的Workerman应用来管理,这样可以提高服务的独立性和可维护性。
status命令会显示每个Worker进程的详细信息,包括进程ID(PID)。虽然你不能直接通过Workerman命令行去操作某个PID,但你可以利用这些信息进行系统层面的管理。比如,如果你发现某个特定的Worker进程(通过
status看到的PID)内存泄漏严重,你可以在系统层面使用
kill [PID]命令来强制杀死它。Workerman的主进程会检测到子进程的退出,并自动拉起一个新的子进程来替代它,这在一定程度上也能实现“局部重启”,但这不是Workerman命令行提供的直接功能,而是利用了操作系统的进程管理机制。
总的来说,Workerman的命令行设计是简洁而高效的,它专注于对整个应用实例的生命周期管理。对于更细粒度的控制,我们通常会考虑将服务拆分,或者在系统层面结合
ps、
kill等命令进行辅助管理。









