Inconsistent PDF report generation with wkhtmltopdf (code:9)

(9 posts) (2 voices)

Tags:

No tags yet.

  1. rmanes, Member

    We have been receiving the following error intermittently across several reports:
    There was an error (code:9) producing the pdf document
    What does this mean, and what can we do to fix it?

    The errors seem to come in spurts and then mysteriously stop occurring.

    When I copy the command that is shown with the error code and run it at the shell command line, I receive the following response:
    Exit with code 1 due to network error: HostNotFoundError
    The temporary html file is not in the tmp folder; however, I don't believe I've witnessed a case during my monitoring where the temp file wasn't generated and then deleted (the few times I've been able to monitor the tmp directory when an error occurs).

    I apologize if the answer is already available and my google-fu is inadequate to the task of finding it.

    Thank you for your time

  2. myDBR Team, Key Master

    Hi,
    whe error comes when myDBR calls wkhtmltopdf and wkhtmltopdf fails.

    The first thing to check is the wkhtmltopdf version you are using. You can see that from command line by executing:

    % wkhtmltopdf -V

    The latest version is currently 0.12.2.1 and 0.12.3 is also available for testing at wkhtmltopdf.org.

    If you find a use case where the PDF generation fails, you can use

    select 'dbr.export.options', 'debug', 1;

    which will not execute the wkhtmltopdf command but shows you the command it would have executed and leaves the workfile in place.

    --
    myDBR Team

  3. rmanes, Member

    Thanks for the reply.

    We're currently running wkhtmltopdf 0.12.3-dev79ff1e (the latest release).

    We've used the debug option in the past to track down other issues, but this one is more difficult since it is intermittent. Is there any other advice/help you can offer?

    Again, thank you for your time.

  4. rmanes, Member

    I guess, to be more specific with my request:
    Is it possible to to see why wkhtmltopdf failed without using debug? Or to still generate a pdf with the web interface while using debug?

    While using the myDBR web interface, is it possible to capture what typically happens when using wkhtmltopdf on the command line when omitting the quiet flag to a file for later viewing?

  5. myDBR Team, Key Master

    wkhtmltopdf dies on same report and in another run it works?

    We added new defaults to wkhtmltopdf (accessible via user/defaults) which might help you:

    $mydbr_defaults['export']['wkhtmltopdf']['clean_tmp_file_in_case_of_error'] = false;
    $mydbr_defaults['export']['wkhtmltopdf']['show_failed_command_to_all'] = true;

    When 'clean_tmp_file_in_case_of_error' is set to false, the temp file is left in place so you can rerun the command from command line. It should produce the same result (an error). If it does not, there is something wrong with the server configuration.

    The 'show_failed_command_to_all' controls just if the actual command is shown to user or just to admin.

    Just run the updater to get the new build.
    --
    myDBR Team

  6. rmanes, Member

    wkhtmltopdf dies on same report and in another run it works?

    Yes. From a web report, we export to pdf and it fails. We hit back and try again, and it works...sometimes. Very frustrating.

    It is almost certainly something to do with our server (as I'm sure you are guessing), but without being to "peek behind the curtain" when something goes wrong, it's challenging to track down.

    I'm very grateful for your help adding the new defaults. We'll post back when we have more information.

    Thank you for your quick response! Seeing your responsiveness to your customers on your forums was one of the reasons we chose myDBR. Thanks again.

  7. rmanes, Member

    One thing I found (it's not the main issue, though) is that around line 14 of export_header_pdf.php, the protocol variable is redefined as 'http' rather than leaving it set to whatever protocol was found earlier - 'https' in our case. Only found this since we're running a server that requires https.

    Also, there was an extra slash in front of 'images/apppic_small.jpg' later in the same file.

    Neither was fatal (in fact, we generated many-a-pdf with those errors present), but they were causing errors and I wanted wkhtmltopdf to run error free for troubleshooting. It now runs error free, but says 'killed' while printing pages.

    So it doesn't look like anything from myDBR (as you probably guessed already), but your help was invaluable. I'll compile wkhtmltopdf from source on our server and see what happens.

    Thank you very much for your time.

  8. myDBR Team, Key Master

    Thanks for pointing out the issues in the header file. Let us know when you find the reason for the crashes. You can also try the alpha version of wkhtmltopdf as it seems to be working bettter for some users.

    --
    myDBR Team

  9. rmanes, Member

    Well, it looks like the problem was that we ran out of resources (RAM).

    I created a large swap file and that seems to have made things better for the most part, but we're moving to a bigger/better/faster server and during testing so far, it has performed flawlessly.

    Thanks again for your help.


Reply

You must log in to post.