1

请注意，我知道这可能不是最好或最佳的方法，但我以前在某个地方遇到过这个问题，我很好奇答案。

我有一个 perl 脚本，它从一个运行并偶尔死掉的 init 中调用。为了快速调试它，我整理了一个快速包装 perl 脚本，它基本上由

#$path set from library call.    
while(1){
  system("$path/command.pl " . join(" ",@ARGV) . " >>/var/log/outlog 2>&1");
  sleep 30; #Added this one later. See below...
}

从命令行启动它，它运行良好且符合预期。command.pl 被调用，脚本基本上停在那里，直到子进程死亡然后再次运行。

但是，当从启动脚本（实际上是通过 start-stop-daemon）调用时，系统命令会立即返回，让 command.pl 继续运行。然后它又转了一圈。一次又一次。（如果没有 sleep 命令，这并不好玩。）。ps 显示（许多）command.pl 的父级为 1，而不是包装脚本的 id（当我从命令行运行时）。

有谁知道发生了什么？

4

3 回答 3

2

也许command.pl没有成功运行。也许该文件没有执行权限（您需要说perl command.pl吗？）。也许您正在从与您想象的不同的目录运行命令，并且command.pl找不到该文件。

您至少可以检查三件事：

  1. 命令的标准错误输出。现在你正在通过说吞下它2>&1。删除该部分并观察system命令产生的错误。
  2. 的返回值system。该命令可能会运行并且system可能仍会返回退出代码，但如果system返回 0，则表明该命令成功。
  3. Perl 的错误变量$!。如果有问题，Perl 会设置$!，这可能有用也可能没用。

总结一下，试试：

my $ec = system("command.pl >> /var/log/outlog");
if ($ec != 0) {
    warn "exit code was $ec, \$! is $!";
}

更新：如果命令的多个实例不断出现在您的ps输出中，那么听起来程序正在分叉并在后台运行。如果这确实是该命令应该执行的操作，那么您不想做的是在无限循环中运行此命令。

于 2012-11-01T19:10:58.197 回答
0

也许从守护进程运行时，“系统”命令使用的 shell 与您自己运行时使用的 shell 不同。也许守护进程使用的 shell 无法识别 >& 构造。

于 2012-11-01T19:00:20.183 回答
-3

如果对您有用，请system("...")尝试功能，而不是。exec("...")

于 2012-11-01T19:01:35.690 回答