从Runtime.getRuntime（）。exec（）启动wkhtmltopdf：永远不会终止？ [英] Launching wkhtmltopdf from Runtime.getRuntime().exec(): never terminates?

问题描述

我正在我的Java应用程序中启动wkhtmltopdf（Tomcat服务器的一部分，在Win7 64位上的Eclipse Helios中以调试模式运行）：我想等待它完成，然后再做更多的东西。

I'm launching wkhtmltopdf from within my Java app (part of a Tomcat server, running in debug mode within Eclipse Helios on Win7 64-bit): I'd like to wait for it to complete, then Do More Stuff.

String cmd[] = {"wkhtmltopdf", htmlPathIn, pdfPathOut};
Process proc = Runtime.getRuntime().exec( cmd, null );

proc.waitFor();

但是 waitFor（）永远不会返回。我仍然可以在Windows任务管理器中看到该过程（我将命令行传递给exec（）：看起来很好）。它的工作原理。 wkhtmltopdf生成我期望的PDF，就在我期望的地方。我可以打开它，重命名它，无论如何，即使进程仍在运行（在我手动终止它之前）。

But waitFor() never returns. I can still see the process in the Windows Task Manager (with the command line I passed to exec(): looks fine). AND IT WORKS. wkhtmltopdf produces the PDF I'd expect, right where I'd expect it. I can open it, rename it, whatever, even while the process is still running (before I manually terminate it).

从命令行开始，一切正常：

From the command line, everything is fine:

c:\wrk>wkhtmltopdf C:\Temp\foo.html c:\wrk\foo.pdf
Loading pages (1/6)
Counting pages (2/6)
Resolving links (4/6)
Loading headers and footers (5/6)
Printing pages (6/6)
Done

进程退出就好了，生活还在继续。

The process exits just fine, and life goes on.

那么 runtime.exec（）是什么造成的？ wkhtmltopdf永远不会终止？

So what is it about runtime.exec() that's causing wkhtmltopdf to never terminate?

我可以抓住proc.getInputStream（）并寻找Done，但那是......卑鄙的。我想要更通用的东西。

I could grab proc.getInputStream() and look for "Done", but that's... vile. I want something that is more general.

我使用和不使用工作目录调用exec（）。我尝试过使用和不使用空的env数组。没有快乐。

I've calling exec() with and without a working directory. I've tried with and without an empty "env" array. No joy.

为什么我的流程挂起，我该怎么做才能修复它？

Why is my process hanging, and what can I do to fix it?

PS：我已尝试使用其他几个命令行应用程序，它们都表现出相同的行为。

PS: I've tried this with a couple other command line apps, and they both exhibit the same behavior.

我正在尝试阅读标准输出&错误，没有成功。从命令行，我知道应该有一些非常类似于我的命令行体验，但当我读取proc.getInputStream（）返回的输入流时，我立即得到一个EOL（-1，我正在使用 inputStream.read（））。

I'm trying to read standard out & error, without success. From the command line, I know there's supposed to be something remarkably like my command line experience, but when I read the input stream returned by proc.getInputStream(), I immediately get an EOL (-1, I'm using inputStream.read()).

我检查了JavaDoc for Process，发现了这个

I checked the JavaDoc for Process, and found this

父进程使用这些流向子进程提供输入并从子进程获取输出。由于某些本机平台仅为标准输入和输出流提供有限的缓冲区大小，因此无法及时写入输入流或读取子进程的输出流可能导致[b]子进程阻塞，甚至死锁[/ b]。

The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the [b]subprocess to block, and even deadlock[/b].

强调增加。所以我试过了。标准输出inputStream上的第一个'read（）'被阻止，直到我杀死进程...

Emphasis added. So I tried that. The first 'read()' on the Standard Out inputStream blocked until I killed the process...

WITH WKHTMLTOPDF

使用通用命令行ap&没有params所以它应该转储使用并终止，它会删除相应的std :: out，然后终止。

With the generic command line ap & no params so it should "dump usage and terminate", it sucks out the appropriate std::out, then terminates.

有趣！

JVM版本问题？我正在使用1.6.0_23。最新的是... v24。我刚刚检查了更改日志并且没有看到任何有希望的东西，但我还是会尝试更新。

JVM version issue? I'm using 1.6.0_23. The latest is... v24. I just checked the change log and don't see anything promising, but I'll try updating anyway.

好的。不要让输入流填充或阻止它们。校验。 .close（）也可以阻止这种情况，但不是很明亮。

Okay. Don't let the Input Streams fill or they'll block. Check. .close() can also prevent this, but isn't terribly bright.

一般情况下（包括我测试过的通用命令行应用程序。

That works in general (including the generic command line apps I've tested).

然而，在具体的中，它会崩溃。似乎wkhtmltopdf正在使用一些终端操作/游标内容来执行ASCII图形进度条。我相信这会导致inputStream立即返回EOF而不是给我正确的值。

In specific however, it falls down. It appears that wkhtmltopdf is using some terminal manipulation/cursor stuff to do an ASCII-graphic progress bar. I believe this is causing the inputStream to immediately return EOF rather than giving me the correct values.

任何想法？很难成为交易破坏者，但肯定会很高兴。

Any ideas? Hardly a deal-breaker, but it would definitely be Nice To Have.

推荐答案

一个进程有3个流：输入，输出和错误。您可以使用单独的进程同时读取输出和错误流。请参阅此问题及其被接受例如，回答和这一个。

A process has 3 streams: input, output and error. you can read both output and error stream at the same time using separate processes. see this question and its accepted answer and also this one for example.

这篇关于从Runtime.getRuntime（）。exec（）启动wkhtmltopdf：永远不会终止？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！