什么是php底层挂起执行,PHP挂起时exec()bash脚本

I believe the rest of the line is suppose to dump any response so the php script can continue running

如果你不明白,这里是解释.如果你有：

exec($this->path.' start > /dev/null 2>&1 &');

> / dev / null部分表示将stdout(即命令生成的常规输出)重定向到/ dev / null(这是空设备).因此,命令本身产生的任何输出都将被抑制.

2>& 1部分意味着将stderror(即由执行命令产生的任何错误)重定向到stdout.但是,由于stdout被重定向到/ dev / null,因此任何错误也将被重定向到那里.因此,使用这两个,它会抑制命令将生成的任何消息.

最后& (&符号)最后将命令分配给新进程.从Bash man page：

If a command is terminated by the control operator &, the shell

executes the command in the background in a subshell. The shell does

not wait for the command to finish, and the return status is 0 (true).

但是,根据this question,你正在做的应该是工作.必须有其他事情来阻止该过程成功分叉.只是为了排除PHP的问题,我首先尝试通过命令行而不是PHP的exec来执行命令.如果它仍然不起作用,我猜它是因为你的Job Control有问题.要么它以某种方式被禁用.我没有在PHP中尝试过这个,但您可以使用set -m命令(启用作业控制)来启用它.注意,要禁用作业控制而不是设置-m,请设置m.以下是如何在PHP中执行此操作：

exec('set -m && ' . $this->path.' start > /dev/null 2>&1 &');

您可以做的另一件事是在PHP脚本执行时,登录命令行并键入命令作业并查看其输出.如果它是空白的,PHP不会正确分配作业.你应该看到类似的东西：

[1]+ Stopped your_command.sh

注意这里说停止了.如果进程仍在运行,则可能不会停止此操作.

您可以做的另一件事是查看是否启用了checkjobs.登录服务器并执行以下命令以获取内置shell optional behavior：

shopt -p | grep checkjobs

如果输出是shopt -u checkjobs,这不是问题.如果它反过来说shopt -s checkjobs,这可能会导致你看到的行为,因为用后台作业杀死一个shell会导致一个错误,说有工作正在运行,你实际上必须杀死shell两次才能摆脱它.也许这是PHP开发人员没有考虑的事情.在这种情况下,前置shopt -u checkjobs&&在PHP中执行命令之前.

exec('shopt -u checkjobs && ' . $this->path.' start > /dev/null 2>&1 &');