7

我正在尝试从我的 java 代码中执行一个脚本，如下所示：

Process p = Runtime.getRuntime().exec(cmdarray, envp, dir); // cmdarray is a String array
// consisting details of the script and its arguments

final Thread err = new Thread(...); // Start reading error stream
err.start();
final Thread out = new Thread(...); // Start reading output stream
out.start();
p.waitFor();
// Close resources

脚本的执行结束了（它的 pid 已经没有了），但是 java 卡在waitFor()了进程的方法上！。是的，我正在 2 个单独的线程中读取输出和错误流。是的，他们在最后（之后waitFor()）加入。

该脚本基本上会安装一些 RPM（比如 10 个左右）并对其进行配置。所以脚本运行了 60 多秒。

它看起来类似于以下内容：

#!/bin/sh

#exec 3>&1 >/var/log/some_log 2>&1

# If the above line is uncommented, Java recognizes that the 
# process is over and terminates fine.

tar xzf a-package-having-rpms.tar.gz
cd unpacked-folder
(sh installer-script.sh) #This installs 10 odd rpms in a subshell and configures them
cd ..
rm -rf unpacked-folder

exit 0

令人震惊的是，如果我在脚本中添加以下行（在顶部），Java 会理解脚本已经结束并且它会完美地终止该过程。

exec 3>&1 > /var/log/some_log 2>&1

作为记录，该脚本不会生成任何输出。零字符！所以把 exec 语句放在那里是没有意义的！

但是，神奇的是，将 exec 语句放入脚本中可以使 java 工作！为什么？？

如何避免脚本中不合逻辑的 exec 语句？

如果您对 installer-script.sh 的外观感兴趣，那么：

#!/bin/sh

exec 3>&1 >>/var/log/another-log.log 2>&1
INSDIR=$PWD
RPMSDIR=$INSDIR/RPMS
cd $RPMSDIR
#
rpm -i java-3.7.5-1.x86_64.rpm
rpm -i --force perl-3.7.5-1.x86_64.rpm
rpm -i --nodeps mysql-libs-5.0.51a-1.vs.i386.rpm
rpm -i --nodeps mysql-5.0.51a-1.vs.i386.rpm
rpm -i --nodeps mysql-server-5.0.51a-1.vs.i386.rpm
rpm -i --nodeps perl-DBD-MySQL-3.0007-2.el5.i386.rpm
rpm -i --nodeps perl-XML-Parser-2.34-6.1.2.2.1.i386.rpm
.
.
.

现在，为什么 Java 需要第一个脚本中的 exec 命令才能知道进程已经结束？我怎样才能避免那个执行？，尤其是。因为第一个脚本不产生任何输出。

屏住呼吸等待答案！

4

7 回答 7

8

我的猜测是，Java 认为脚本不会结束，直到它通过 stdin/stdout/stderr 传递给它的管道被子进程关闭。也就是说，stdin 上不再有活动的读取器进程，stdout/stderr 上不再有活动的写入器进程。

当您在管道上阅读时，您不会收到文件结束指示，直到没有更多进程打开管道以进行输出。因此，如果一个进程分叉并且新进程继承了一个打开的文件句柄，那么原始进程将终止，仍然有一个进程打开文件，读取器仍然会等待。

与您正在编写的管道类似，在最后一个阅读器关闭管道之前，您不会收到“管道损坏”信号。

当您的脚本分叉继承 stdin/stdout/stderr 的后台任务（如新安装的服务）时，通常会出现此问题。

通过使用 exec，您明确地破坏了这些管道的继承链，以便后台进程不使用它们。

如果在 Linux 上，检查 /proc/*/fd 是否有任何新服务，并查看它们的 stdin/stdout/stderr 是否与您的 java 进程传递给脚本的管道相同。

同样的情况在您运行 /etc/init.d/xxx 脚本时经常发生：当您从命令行运行它们时它们正常完成，但当您从某种监视器运行它们时它们似乎挂起。

编辑：

您说安装程序脚本包含以下行：

exec 3>&1 >>/var/log/another-log.log 2>&1

第一个术语 3>&1 将 stdout 克隆到文件描述符 3（请参阅man bash 中的重定向）。据我所知，fd 3 没有什么特殊含义。然后它通过打开 /var/log/another-log.log 替换 stdout，并通过克隆 stdout 替换 stderr。请参阅 bash 手册页的重定向部分

这意味着新的文件描述符 3 已打开以在最初作为 STDOUT 传入的管道上进行写入。期望成为系统服务守护进程的程序通常会关闭文件描述符 0 (STDIN)、1 (STDOUT) 和 2 (STDERR)，但可能不会打扰其他任何文件。此外，既然 shell 已经打开了 FD-3，它会将打开的文件传递给它执行的任何命令，包括后台命令。

您知道安装程序打开 FD 3 是否有任何特殊原因？我的猜测是，如果您只是从安装程序中删除“3>&1”术语，您的问题就会得到解决。这将允许您完全从脚本中删除 exec

于 2010-08-14T23:40:06.913 回答
1

一个可能的原因是安装软件包会启动后台进程，这些进程使您的一个或两个管道（stdout/stderr）保持打开状态。因此，您的线程不会终止。这意味着这些后台进程没有正确地守护进程。适当的守护程序在完成初始化后用 /dev/null 或日志文件替换其原始 stdin/stdout/stderr。

于 2010-08-14T23:30:02.127 回答
0

如果您在 Linux/Unix 上运行，请尽量不要使用 stdout/stderr。

上次我不得不从 Java 运行外部脚本时，我最终不得不检查操作系统并仅在 Windows 上附加输出吃线程。

于 2010-08-14T17:39:55.913 回答
0

听起来您正在理解问题的一些细节，但您仍然没有完全了解“大图”。

  1. 是的，可以从 Java 程序调用 shell 脚本。简单，事实上！<= 你已经知道了。

  2. 是的，通常，您应该能够看到打印到 stderr 或 stdout 的任何内容。

  3. 是的，您应该能够将 stderr 和/或 stdout 重定向到文件。

  4. 你的问题显然是你没有看到你期望看到的，当你期望看到它时。这是正常的，这是意料之中的......而且，在更大的计划中，这是非常可取的。

我相信，核心问题是“I/O 缓冲”。

缓冲是一件好事。

我强烈建议您： 1. 创建一个简单的单线程命令行 Java 测试程序，该程序调用一个 shell 脚本。<= 你应该看到“预期结果”

  1. 用线程细化测试程序。根据程序的结构，您可能会也可能不会获得“预期结果”。

  2. 用 C 程序（或其他 Java 程序）替换 shell 脚本 <= 这使得使用“stderr”更容易，它是 UNBUFFERED，与“stdout”你也应该放弃“exec”的废话——这是一个红鲱鱼！

  3. 实验，看看你学到了什么。

祝你好运——请不要直接跳到第一个看似合理的结论。总是测试你的理论。

PS：重复我的口头禅：“I/O 缓冲很好”;-)

PP:

问：这个问题到目前为止只被浏览了 38 次！

A：“你必须学会​​耐心，年轻的蚱蜢”;-)

问：这对我来说有点关键！

A：“你也必须学会谦逊”;-)

于 2010-08-15T21:25:06.667 回答
0

我没有在 Linux 中尝试过，但我在 Windows 中遇到了这个问题。我想我必须在流程终止之前关闭流程的标准。

于 2010-08-14T18:17:04.780 回答
0

我也会抽标准输入。泵送所有三个标准流是个好主意。我无法解释，但在进程挂起之前我也遇到过类似的问题，问题在于缺少标准输入泵。

于 2010-08-14T17:49:49.653 回答
-1

您只是不能从 Java 执行脚本并等待它。您必须执行该脚本的解释器。cmdarray 应该以“bash”而不是“myscript.bash”开头。

于 2010-08-14T22:57:51.083 回答