WKHTMLTOPDF not shutting down processes when done

Steve Allan

unread,

Nov 10, 2015, 2:24:01 PM11/10/15

to wkhtmltopdf General

I'm using wkhtmltopdf version 0.2.2.1 (with patched qt) on a linux server (managed by a hosting company) to generate HTML to PDF's.

I have an issue where the wkhtmltopdf processes aren't getting killed correctly. A user recently generated several PDFs on the site before it failed to generate anymore.

I checked with the host provider and there were 44 wkhtmltopdf processes running (some had probably been running for several days).

I'm calling it from PHP using the command

system("wkhtmltopdf -O landscape --disable-smart-shrinking $tempHTML $tempPDF");

The first time I hit this problem I figured that it was returning a confirmation message (such as for confirming overwriting a file) so I checked for the existence of the PDF before calling wkhtml and deleting the file if it did exist.

I then made several tests, generating the same PDF's several times. They all printed as they should and the host confirmed there were no still running processes and so I thought the problem was resolved.

Now, it obviously isn't.

The relevant chunk of PHP code is:

$tempHTML = $pdfPath . "/" . $categoryName . ".html";

$tempPDF = $pdfPath . "/" . $categoryName . ".pdf";

if(file_exists($tempPDF)) {

unlink($tempPDF);

}

$result = file_put_contents($tempHTML, $pdf_str);

system("wkhtmltopdf -O landscape --disable-smart-shrinking $tempHTML $tempPDF");

unlink($tempHTML);

header('Content-Type: application/pdf');

header('Content-Disposition: attachment; filename='.basename($tempPDF));

header('Cache-Control: no-cache');

header("Accept-Ranges: none");

readfile($tempPDF);

ob_clean();

ob_end_flush();

Yozons eSignForms

unread,

Nov 10, 2015, 3:14:01 PM11/10/15

to wkhtmltopdf General

I don't use PHP, but in Java we fork the process and "read" the stdout/stderr streams (they will have any errors/debug messages to help troubleshoot, so it's a good idea anyway) that allows the process to complete.

To see if this is a problem here, you can probably adjust the 'system' call by appending ">/dev/null 2>&1" and see if the process then completes (or you can point to a log file instead of /dev/null to keep a copy).

Steve Allan

unread,

Nov 11, 2015, 3:16:03 PM11/11/15

to wkhtmltopdf General

Thanks for the advice.

I added that in and generated as many PDFs as it took to experience the stalling (~33 but the size of each one varies).

All of the ones before the stall logged a complete job and handled missing images and the like OK. The one that stalled had this as the log:

Loading pages (1/6)

[> ] 0%

[======> ] 10%

[========> ] 14%

[=============> ] 22%

[===============> ] 26%

[================> ] 28%

[==================> ] 30%

[====================> ] 34%

[========================> ] 40%

[=========================> ] 43%

[===========================> ] 45%

[============================> ] 47%

[=============================> ] 49%

[====================================> ] 61%

[=============================================> ] 75%

[==============================================> ] 78%

[====================================================> ] 88%

Warning: Failed to load <image>.jpg (ignore)

[============================================================] 100%

Counting pages (2/6)

[============================================================] Object 1 of 1

Resolving links (4/6)

[============================================================] Object 1 of 1

Loading headers and footers (5/6)

Printing pages (6/6)

[> ] Preparing

[====> ] Page 1 of 14

[========> ] Page 2 of 14

[============> ] Page 3 of 14

[================> ] Page 4 of 14

[=====================> ] Page 5 of 14

[=========================> ] Page 6 of 14

[==============================> ] Page 7 of 14

Corrupt JPEG data: premature end of data segment

[==================================> ] Page 8 of 14

[======================================> ] Page 9 of 14

[==========================================> ] Page 10 of 14

[==============================================> ] Page 11 of 14

[===================================================> ] Page 12 of 14

[=======================================================> ] Page 13 of 14

[============================================================] Page 14 of 14

Done

Loading pages (1/6)

[> ] 0%

[======> ] 10%

[=======> ] 13%

[==========> ] 17%

[===========> ] 19%

[=============> ] 22%

[===============> ] 25%

[================> ] 27%

[=================> ] 29%

[===================> ] 33%

[=====================> ] 35%

[======================> ] 38%

[========================> ] 41%

[==========================> ] 44%

[===========================> ] 46%

[============================> ] 48%

[==============================> ] 50%

[===================================> ] 59%

[=======================================> ] 66%

[==========================================> ] 71%

[=============================================> ] 76%

[===============================================> ] 79%

[=================================================> ] 83%

[===================================================> ] 86%

So I'm thinking at that point it hit some kind of memory issue. It isn't related to the PDF being generated as I generated each one at least twice getting to the stall point.

This could be server related as well but has anyone had any experience of wkhtmltopdf having issues like this?

Thanks

Yozons eSignForms

unread,

Nov 12, 2015, 1:38:12 PM11/12/15

to wkhtmltopdf General

No real idea, but this looks like it could be the cause of a PDF failure, though not why the Linux process would not terminate:

Reply all

Reply to author

Forward