Need help wkhtmltopdf exited on signal 10 (core dumped) on FreeBSD 14.2

R

rai.mohammed

Hello everyone,

Trying to deploy an Odoo 18 CE Server from GitHub and configuring Apache Web Server 2.4.62 with HTTPS support, I tested the installation, and all the system works well even printing a PDF invoice or a sale order.

The requirement for Odoo 17.0 or Odoo 18.0 needs wkhtmltopdf version : 0.12.6.1-3, sad to say that is not present on FreeBSD ports.

The OS : FreeBSD 14.2-RELEASE-p1 GENERIC amd64
The wkhtmltopdf version installed from ports : wkhtmltopdf 0.12.6 (with patched qt).

Unfortunately when I try to print other reports or options from the UI of the Odoo Server, I get an issue with wkhtmltopdf failing with error : [Invalid Operation Wkhtmltopdf failed (error code: -10)].
Even I did a test print from the cmd to an external URL and the URL of my internal Odoo server :
Code: 
root@desktopfreebsd:~ # wkhtmltopdf https://www.youtube.com /root/Downloads/youtube_com.pdf
Loading pages (1/6)
Segmentation fault (core dumped)                             ] 47%
root@desktopfreebsd:~ # wkhtmltopdf https://www.yahoo.com /root/Downloads/yahoo_com.pdf
Loading pages (1/6)
Segmentation fault (core dumped)                             ] 10%
root@desktopfreebsd:~ # wkhtmltopdf https://www.odoo17ce.itlinker.local /root/Downloads/odoo17ce_itlinker_local.pdf
Loading pages (1/6)
Warning: SSL error ignored                                   
Warning: SSL error ignored                                   
Warning: SSL error ignored
Warning: SSL error ignored
Warning: SSL error ignored
Warning: SSL error ignored
Counting pages (2/6)                                           
Resolving links (4/6)                                                   
Loading headers and footers (5/6)                                       
Printing pages (6/6)
Done         
root@desktopfreebsd:~ # dmesg | grep "core dumped"
[8732] pid 22607 (wkhtmltopdf), jid 0, uid 1001: exited on signal 10 (core dumped)
[9076] pid 39428 (wkhtmltopdf), jid 0, uid 0: exited on signal 11 (core dumped)
[9136] pid 44041 (wkhtmltopdf), jid 0, uid 0: exited on signal 11 (core dumped)
[9473] pid 63450 (wkhtmltopdf), jid 0, uid 1001: exited on signal 10 (core dumped)
[11412] pid 78091 (wkhtmltopdf), jid 0, uid 0: exited on signal 11 (core dumped)
[11434] pid 79403 (wkhtmltopdf), jid 0, uid 0: exited on signal 11 (core dumped)
[11563] pid 95805 (wkhtmltopdf), jid 0, uid 1001: exited on signal 10 (core dumped)

So I searched the Web for a solution to overcomes the issue for FreeBSD Wkhtmltopdf failed (error code : -10), I got a workaround fix to set up and install a CentOS 7 version of wkhtmltopdf in linux mode for FreeBSD.

Unlucky and unhappy I am, the problem this time, wkhtmltopdf throws another error: "Cannot open an empty file" from the reports, and besides other documents cannot be printed at all, and shows an empty PDF page.
The issue persists even after installing a version of wkhtmltopdf related to Rocky Linux 9.5 with all the requirements in Linux mode for FreeBSD.

Please, can someone have a solution or a fix for this use case of integrating wkhtmltopdf with Odoo in FreeBSD, and at least is to update wkhtmltopdf package to the latest version.
As you can guess, the whole system is useless without the functionality of printing the obligatory and essential reports.
In addition, remembering to point out that a large majority of web applications using the current wkhtmltopdf from FreeBSD ports as a dependency, will have the same problem and will not work.
 
Last edited:
if it works with -n for the pages you care and you can't configure the Odoo Server to pass -n just create a shell script with the same name in the same place which invokes the real program with -n
Code: 
 1 #!/bin/sh
 2 exec /usr/local/bin/wkhtmltopdf.bin -n "$@"
for me it works better with -n but still core dumps on some pages
 
covacat said:
if it works with -n for the pages you care and you can't configure the Odoo Server to pass -n just create a shell script with the same name in the same place which invokes the real program with -n
Code: 
 1 #!/bin/sh
 2 exec /usr/local/bin/wkhtmltopdf.bin -n "$@"
for me it works better with -n but still core dumps on some pages
Click to expand...
I added this shell script :
Code: 
root@desktopfreebsd:~ # mv /usr/local/bin/wkhtmltopdf /usr/local/bin/wkhtmltopdf.bin
root@desktopfreebsd:~ # mv /usr/local/bin/wkhtmltoimage /usr/local/bin/wkhtmltoimage.bin

root@desktopfreebsd:~ # cat /usr/local/bin/wkhtmltopdf
#!/bin/sh
exec /usr/local/bin/wkhtmltopdf.bin -n "$@"

root@desktopfreebsd:~ # cat /usr/local/bin/wkhtmltoimage
#!/bin/sh
exec /usr/local/bin/wkhtmltoimage.bin -n "$@"

root@desktopfreebsd:~ # chmod +x /usr/local/bin/wkhtmltopdf
root@desktopfreebsd:~ # chmod +x /usr/local/bin/wkhtmltoimage

root@desktopfreebsd:~ # ls -al /usr/local/bin/wkhtmltopdf
-rwxr-xr-x 1 root wheel 50 Feb 26 19:12 /usr/local/bin/wkhtmltopdf
Then I changed the param in [Settings / Technical / Parameters / System Parameters] - webkit=/usr/local/bin/wkhtmltopdf
But without success
 
Last edited:
Ooh, I am interested into running Odoo on FreeBSD, sad to see it seems to run into some issues. I had understood that "wkhtmltopdf" was already integrated onto Odoo by now.
 
In a later stage I will try out the latest Odoo port, and I will post my findings on this post (or maybe a new one dedicated to this Odoo port?). In the meantime, I would love to hear feedback from anyone trying out the install c:
 
Hi everyone,

I wanted to post an update and the final, working solution for the wkhtmltopdf issue with Odoo on FreeBSD 14.2, as we were able to find and fix the root cause after a long analysis.

A big thank you to everyone who helped in this thread.

Summary of the Problem:

The core issue is that wkhtmltopdf, in the version required by Odoo (0.12.6+), depends on a very old version of the QtWebKit library. This library has been removed from the FreeBSD Ports Tree for security and maintenance reasons (qt5-webkit is no longer available). Therefore, compiling wkhtmltopdf natively on a modern FreeBSD system is practically impossible and a dead end.

The Solution: The FreeBSD Linuxulator

The only stable and future-proof solution is to use FreeBSD's Linux compatibility layer ("Linuxulator"). This involves running a pre-compiled Linux version of wkhtmltopdf.

The Key Findings:

  1. The Right Combination is Everything: You must use a wkhtmltopdf binary that matches the installed Linux environment. A binary built for CentOS 7 works best with FreeBSD's CentOS 7 base (linux_base-c7). Trying to mix Debian binaries with Rocky Linux environments leads to endless library conflicts (e.g., libssl.so.10 vs. libssl.so.3).
  2. Missing Libraries: The linux_base-c7 package alone is not enough. You need the linux-c7-xorg-libs meta-package to provide all the basic graphics and rendering libraries (libjpeg, libpng, libXrender, etc.), as well as the essential libssl.so.10.
  3. The Font Problem (Empty PDFs): This is the final and most crucial trick. The Linux environment runs in a "jail" (chroot) and cannot see the fonts on the FreeBSD host. This results in the Fontconfig error: Cannot load default config file error. You have to mount the FreeBSD fonts directory (/usr/local/share/fonts) into the Linux environment using nullfs.
Below is a complete step-by-step guide that leads to success from a clean FreeBSD system. I hope this guide helps others save the hours we invested!

Part 2: The Complete Guide​

(GUIDE) How to Install wkhtmltopdf 0.12.6 for Odoo on FreeBSD 14.2

This guide describes how to install a working version of wkhtmltopdf using the FreeBSD Linux compatibility layer ("Linuxulator").

Prerequisites:

  • A running FreeBSD 14.x system.
  • Root privileges.
Step 1: Prepare FreeBSD for Linux Compatibility

# Enable the Linuxulator and have it start on boot
sysrc linux_enable="YES"
# Start the service
service linux start

Step 2: Install the CentOS 7 Linux Environment

We will install the CentOS 7 base and all required graphics, rendering, and font libraries.

pkg install -y linux_base-c7 linux-c7-xorg-libs linux-c7-fontconfig dejavu
  • linux_base-c7: The base operating system.
  • linux-c7-xorg-libs: Provides essential libraries like libjpeg, libpng, libXrender, and libssl.so.10.
  • linux-c7-fontconfig: Provides the configuration for font management.
  • dejavu: A set of high-quality default fonts for the FreeBSD host system.
Step 3: Download and Install the Correct wkhtmltopdf Version

We will use the binary built for CentOS 7, as it perfectly matches our installed environment.
# Switch to a temporary directory
cd /tmp

# Download the wkhtmltopdf RPM file
fetch https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-1/wkhtmltox-0.12.6-1.centos7.x86_64.rpm

# Create a temporary directory for extraction
mkdir temp_rpm
cd temp_rpm

# Extract the RPM archive using bsdtar
bsdtar -xf ../wkhtmltox-0.12.6-1.centos7.x86_64.rpm

# Copy the binaries to their final destination
cp -f ./usr/local/bin/wkhtmltoimage /usr/local/bin/
cp -f ./usr/local/bin/wkhtmltopdf /usr/local/bin/

# Clean up
cd /tmp
rm -rf temp_rpm wkhtmltox-0.12.6-1.centos7.x86_64.rpm
Step 4: Permanently Fix the Font Problem (Crucial Step)

We need to make the FreeBSD system's fonts visible to the Linux environment.

# 1. Create a mountpoint inside the Linux system
mkdir -p /compat/linux/usr/share/fonts

# 2. Mount the FreeBSD fonts into the Linux system using nullfs<
mount -t nullfs /usr/local/share/fonts /compat/linux/usr/share/fonts

# 3. Add the mount to /etc/fstab to make it permanent across reboots<
echo '/usr/local/share/fonts /compat/linux/usr/share/fonts nullfs ro 0 0' >> /etc/fstab

# 4. Rebuild the font cache inside the Linux environment
chroot /compat/linux /usr/bin/fc-cache -f -v
Step 5: Test and Finalize

Run a final test to verify functionality.

/usr/local/bin/wkhtmltopdf https://www.google.com google_final.pdf

You should now see no errors, and the created google_final.pdf file should be a fully rendered webpage with text and images.

Your wkhtmltopdf is now correctly configured and ready to use.
 
hat's an excellent suggestion and you are absolutely right about the future. WeasyPrint is a modern, actively maintained engine and the way forward for new projects. The print/py-weasyprint port is definitely the cleaner, native FreeBSD solution.

The main challenge, specifically for Odoo, is that Odoo is hard-coded to call the wkhtmltopdf binary. It uses a specific set of command-line arguments for headers, footers, margins, etc., that WeasyPrint does not understand out of the box.

To use WeasyPrint, one would need to create a "wrapper script" that intercepts the wkhtmltopdf calls from Odoo and translates them into WeasyPrint-compatible commands. While this is certainly possible, it's a significant development effort and might require ongoing maintenance as Odoo evolves.

Conclusion:
  • For a "just works" solution to get Odoo running now, the Linuxulator method is currently the most practical and proven path, despite its complexity.
  • For the long-term health of Odoo on FreeBSD, transitioning to WeasyPrint would be the ideal goal. This might be a great project for the community – perhaps developing a standard wrapper script or even patching Odoo itself to support WeasyPrint as an alternative rendering engine.
Thank you for bringing this up, it's a very important point for the future!
 
Final follow-up on the suggestion to use WeasyPrint. I tested it against the wkhtmltopdf Linuxulator setup to see the difference.

Test: I rendered google.com with both tools. The result is conclusive.

1749465423255.png


  • Left (WeasyPrint): The PDF is missing all dynamically loaded UI elements.
  • Right (wkhtmltopdf): The PDF is a pixel-perfect replica of the live site.
Analysis:
The difference is due to JavaScript execution. wkhtmltopdf uses the QtWebKit browser engine and runs JavaScript, ensuring dynamic content is rendered. WeasyPrint is a standards-based parser and does not execute JavaScript, so it misses any script-generated content.

Conclusion:
For rendering complex reports from applications like Odoo, which may rely on dynamic HTML, wkhtmltopdf provides significantly higher fidelity. The Linuxulator setup, while complex, remains the most reliable solution for this specific use case.
 
satriani said:
For rendering complex reports from applications like Odoo, which may rely on dynamic HTML, [...]
Click to expand...
That is one of the things that's just completely wrong when it comes to modern applications...
Why on earth would it have to rely on "dynamic HTML". It's so easy to assemble an HTML DOM and serve it statically. Don't even have to go the full DOM way, often, a tempting engine (like inja) will get you there just fine.
 
This is a fantastic question, and it gets to the very heart of why this problem is so tricky. From a purist software architecture perspective, you are absolutely correct. Server-side rendering of a static HTML document for printing is the most robust approach.

However, the issue lies in Odoo's architecture.

Odoo is not a classic website; it's a Rich Web Application (RWA) built on its own JavaScript framework (the Owl Framework). The key principle at play here is code reusability.

  1. Browser View: When Odoo displays a sales order or a report on the screen, it's rendered dynamically in the browser by the JavaScript framework.
  2. Print Action: When you click "Print," Odoo takes a very efficient shortcut. Instead of re-implementing the entire rendering logic on the server with a templating engine, it simply takes the final, dynamically generated HTML from the browser view and passes it to the wkhtmltopdf process.
This means the HTML being converted is the "live" output of a complex JavaScript application, not simple, static template code.

This architectural choice is precisely why a renderer with a full browser engine (wkhtmltopdf) is required, and why a simpler parser (WeasyPrint, xhtml2pdf) or a server-side templating engine alone is insufficient. They cannot faithfully reproduce the final, client-side rendered document.

It's a classic case of architectural trade-offs: Odoo chose to re-use their web rendering code for efficiency, which in turn creates this very specific dependency on a tool that can act like a real browser.
 
satriani said:
Hi everyone,

I wanted to post an update and the final, working solution for the wkhtmltopdf issue with Odoo on FreeBSD 14.2, as we were able to find and fix the root cause after a long analysis.

A big thank you to everyone who helped in this thread.

Summary of the Problem:

The core issue is that wkhtmltopdf, in the version required by Odoo (0.12.6+), depends on a very old version of the QtWebKit library. This library has been removed from the FreeBSD Ports Tree for security and maintenance reasons (qt5-webkit is no longer available). Therefore, compiling wkhtmltopdf natively on a modern FreeBSD system is practically impossible and a dead end.

The Solution: The FreeBSD Linuxulator

The only stable and future-proof solution is to use FreeBSD's Linux compatibility layer ("Linuxulator"). This involves running a pre-compiled Linux version of wkhtmltopdf.

The Key Findings:

  1. The Right Combination is Everything: You must use a wkhtmltopdf binary that matches the installed Linux environment. A binary built for CentOS 7 works best with FreeBSD's CentOS 7 base (linux_base-c7). Trying to mix Debian binaries with Rocky Linux environments leads to endless library conflicts (e.g., libssl.so.10 vs. libssl.so.3).
  2. Missing Libraries: The linux_base-c7 package alone is not enough. You need the linux-c7-xorg-libs meta-package to provide all the basic graphics and rendering libraries (libjpeg, libpng, libXrender, etc.), as well as the essential libssl.so.10.
  3. The Font Problem (Empty PDFs): This is the final and most crucial trick. The Linux environment runs in a "jail" (chroot) and cannot see the fonts on the FreeBSD host. This results in the Fontconfig error: Cannot load default config file error. You have to mount the FreeBSD fonts directory (/usr/local/share/fonts) into the Linux environment using nullfs.
Below is a complete step-by-step guide that leads to success from a clean FreeBSD system. I hope this guide helps others save the hours we invested!

Part 2: The Complete Guide​

(GUIDE) How to Install wkhtmltopdf 0.12.6 for Odoo on FreeBSD 14.2

This guide describes how to install a working version of wkhtmltopdf using the FreeBSD Linux compatibility layer ("Linuxulator").

Prerequisites:

  • A running FreeBSD 14.x system.
  • Root privileges.
Step 1: Prepare FreeBSD for Linux Compatibility

# Enable the Linuxulator and have it start on boot
sysrc linux_enable="YES"
# Start the service
service linux start

Step 2: Install the CentOS 7 Linux Environment

We will install the CentOS 7 base and all required graphics, rendering, and font libraries.

pkg install -y linux_base-c7 linux-c7-xorg-libs linux-c7-fontconfig dejavu
  • linux_base-c7: The base operating system.
  • linux-c7-xorg-libs: Provides essential libraries like libjpeg, libpng, libXrender, and libssl.so.10.
  • linux-c7-fontconfig: Provides the configuration for font management.
  • dejavu: A set of high-quality default fonts for the FreeBSD host system.
Step 3: Download and Install the Correct wkhtmltopdf Version

We will use the binary built for CentOS 7, as it perfectly matches our installed environment.
# Switch to a temporary directory
cd /tmp

# Download the wkhtmltopdf RPM file
fetch https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-1/wkhtmltox-0.12.6-1.centos7.x86_64.rpm

# Create a temporary directory for extraction
mkdir temp_rpm
cd temp_rpm

# Extract the RPM archive using bsdtar
bsdtar -xf ../wkhtmltox-0.12.6-1.centos7.x86_64.rpm

# Copy the binaries to their final destination
cp -f ./usr/local/bin/wkhtmltoimage /usr/local/bin/
cp -f ./usr/local/bin/wkhtmltopdf /usr/local/bin/

# Clean up
cd /tmp
rm -rf temp_rpm wkhtmltox-0.12.6-1.centos7.x86_64.rpm
Step 4: Permanently Fix the Font Problem (Crucial Step)

We need to make the FreeBSD system's fonts visible to the Linux environment.

# 1. Create a mountpoint inside the Linux system
mkdir -p /compat/linux/usr/share/fonts

# 2. Mount the FreeBSD fonts into the Linux system using nullfs<
mount -t nullfs /usr/local/share/fonts /compat/linux/usr/share/fonts

# 3. Add the mount to /etc/fstab to make it permanent across reboots<
echo '/usr/local/share/fonts /compat/linux/usr/share/fonts nullfs ro 0 0' >> /etc/fstab

# 4. Rebuild the font cache inside the Linux environment
chroot /compat/linux /usr/bin/fc-cache -f -v
Step 5: Test and Finalize

Run a final test to verify functionality.

/usr/local/bin/wkhtmltopdf https://www.google.com google_final.pdf

You should now see no errors, and the created google_final.pdf file should be a fully rendered webpage with text and images.

Your wkhtmltopdf is now correctly configured and ready to use.
Click to expand...
Hello everyone, and thank you, Mr. satriani for providing the solution.

As a reminder, I used the same method to integrate wkhtmltopdf on CentOS 7 and Rocky Linux 9.5, with the only difference being that I didn't configure the step 4.
I'm definitely going to reinstall my environment as you recommended, and I'll keep you updated on the progress.
However, at this point, I'm in the process of customizing my DZ l10n localization in Odoo.
Thank you very much for your help and replay.
 
@satrini, thank you very much for the guide! This will be very useful for anyone in the future looking to install Odoo on FreeBSD.

As I understand it, you took a path of installing "manually". Did you check out the port finance/odoo?

I will update my findings when I try installing it.
 
I’m aware of the finance/odoo port, but it doesn’t suit my needs.
Unfortunately, I have to disappoint you - the problems with wkhtmltopdf persist. I’m afraid wkhtmltopdf is beyond saving at this point.
I’m currently working on an alternative to wkhtmltopdf. I’ll report back if there’s any success.
 
You must log in or register to reply here.
Back
Top