Stop Failure

Phenomenon:

Running php start.php stop prompts stop fail

Possibility One

Prerequisite: Workerman is started in debug mode, and the developer pressed ctrl z in the terminal, sending the SIGSTOP signal to Workerman, causing it to enter the background and suspend (paused), thus unable to respond to the stop command (SIGINT signal).

Solution:
In the terminal where Workerman was started, input fg (sending SIGCONT signal) and then press Enter to bring Workerman back to the foreground, then press ctrl c (sending SIGINT signal) to stop Workerman.

If it cannot be stopped, try running the following two commands:

killall -9 php

ps aux|grep -i workerman|awk '{print $2}'|xargs kill -9

Possibility Two

The user running the stop command is different from the user who started Workerman, meaning the stop user does not have permission to stop Workerman.

Solution:
Switch to the user who started Workerman, or stop Workerman using a user with higher permissions.

Possibility Three

The PID file of the Workerman main process has been deleted, causing the script to be unable to find the PID process, leading to the stop failure.

Solution:
Save the PID file to a secure location, refer to the manual Worker::$pidFile.

Possibility Four

The process corresponding to the Workerman PID file is not a Workerman process.

Solution:
Open the PID file of the Workerman main process to check the main process PID; the PID file is usually in the parallel directory of Workerman. Run the command ps aux | grep main process pid to see if the corresponding process is a Workerman process. If not, the server may have been restarted, causing Workerman to save an expired PID, which is now being used by another process, leading to the stop failure. If this is the case, simply delete the PID file.

Possibility Five

The grpc extension is installed, but the corresponding environment variables for the grpc extension have not been set, causing an additional mount process to fork out after startup, which leads to a failure during stopping.