php在执行外部sh脚本时冻结

我将尝试在时间线历史中解释我的问题：

我尝试从php运行几个外部脚本，并再次使用ajax调用将退出代码返回到服务器。 单次呼叫应启动或停止该机器上的服务。在这台显影机上效果很好

• 操作系统：拉斯比操作系统
• 网络服务器：nginx1.2.1
• Php:5.4.3.6

然而，我已经将代码导出到一台功率更大的机器上，一切似乎都很好，但有一件事： 一个调用就会导致php fpm冻结，再也不会回来。通过详细检查，我发现这个调用创建了一个我无法终止的僵尸进程（即使使用sudo）

• 操作系统：Ubuntu
• 网络服务器：nginx1.6.2
• Php:5.5.9

唯一的解决方案似乎是停止php fpm进程，然后重新启动它。然后，只要我再次尝试调用该脚本，一切似乎都会恢复正常

调用php行

exec("sudo ".$script, $output, $return_var);

（所有变量都是正常的“字符串”，没有特殊字符）

开始脚本

#!/bin/sh
service radicale start 2>&1

顺便说一下，服务启动了，但每次web服务器冻结时，我都必须手动重新启动php，但这是不可接受的（即使对于web服务器也是如此）。但只适用于单个脚本，也只适用于带有庄严命令（start）的服务（radicale）

在Google中搜索使我意识到php命令exec（）和session\u start（）之间存在冲突

链接：

他们的结论是，这个bug可以通过这样的构造来解决：

...
session_write_close();
exec("sudo ".$script, $output, $return_var);
session_start();
...

但是，在我看来，这不是调试，而是一个无助的解决办法，因为你失去了让用户知道他的操作已经完全运行的功能，但更多的是让他相信发生了错误。更令人困惑的是，它完全在Raspberry Pi A上运行，而不是在具有更大CPU和8GB RAM的64位机器上运行

那么，在任何地方都有真正的解决方案吗？或者这是解决问题的唯一方法吗？我读过一篇关于php在exec/shell\u exec和返回值识别方面存在一些问题的文章？那怎么会丢失呢？有人在猜

---

感谢您阅读这么长的糟糕英语，但我不是母语人士，在课堂上也不是听力很好的学生。

很可能新机器的设置方式与覆盆子PI的设置方式不同-

您需要在shell中执行一些操作，然后才能在更大的机器上工作：

1） 。允许php使用sudo

sudo usermod-G sudo-a您的php用户

请注意，要获取php用户的用户名，只需运行一个脚本：

-或者：

-

2） 。允许该用户在没有密码的情况下使用

sudo

sudo-visudo

-此命令将打开带有故障保护的

/etc/sudoers

，以防止您篡改任何内容

将这一行添加到最末尾：

php用户ALL=（ALL）NOPASSWD:/path/to/your/script、/path/to/other/script

您可以根据需要在那里放置任意多个脚本，并用逗号分隔。 现在，您的脚本应该可以正常工作了

同样，请注意，您需要将

您的php用户

更改为任何php用户

---

希望这有帮助

这不是一个真正的解决方案，但它是一个比没有更好的解决方案

使用调用bash脚本

<?php
...
exec("sudo ".$script, $output, $return_var);
...
?>

到

---

。。。所以，给每一条返回到涅磐的线路发信号，并断开所有子程序。目前，服务器没有挂断自己的连接，而是按预期工作。但是这种感觉可能是php中的一个主要缺陷，我仍然在脑海中挥之不去，希望有一天，有人能战胜这个缺陷。

大家都知道，让php无限制地访问sudo是个坏主意。哦，是的，谢谢你提醒我-我想说的是-@castis-这样更好吗？我已经这样做了。从bash函数运行脚本时不会出错。与旁边的其他脚本（相同的chmod级别）一样，没有问题，我现在正在搜索给定radicale脚本中的错误，以隔离错误，但现在我确信radicale进程正在运行，没有错误。我怀疑php是可疑的，因为无论何时我通过php启动脚本，www根目录都会创建一个无法杀死的僵尸进程，除非重新启动php服务器进程。

sudo su-s/bin/bash

进入php用户-以这种方式运行脚本-看看会发生什么。如果可行，请重新启动系统并重试。如果没有，stderr告诉你什么？Wtf？您的原始脚本是“service radicale start”？你为什么不启动服务，让它继续运行？？这就是服务器的用途。。。此外，这不是PHP中的一个bug，而是编写代码时的一个bug。为了调用这样一个毫无意义的脚本，你没有必要违反良好的实践。事实上，如果用户不需要它，他可以禁用服务，而不调用它。否则，这是否会降低此bug的重要性和问题？你对它的看法很奇怪。

#!/bin/sh
service radicale start 2>&1

#!/bin/sh
service radicale start > /dev/null 2>&1 &