A Docker-powered stateless API for PDF files.

Cloud Run is a managed compute platform that automatically scales your stateless containers. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications

Anyone tried Gotenberg on Cloudrun? Im assuming it would work as its stateless? Could have huge cost savings...

Every so often, the latest 7.5 docker image will crash on startup. Here's the docker logs:

pdfgen_1     | 
pdfgen_1     |   _____     __           __               
pdfgen_1     |  / ___/__  / /____ ___  / /  ___ _______ _
pdfgen_1     | / (_ / _ \/ __/ -_) _ \/ _ \/ -_) __/ _ '/
pdfgen_1     | \___/\___/\__/\__/_//_/_.__/\__/_/  \_, / 
pdfgen_1     |                                    /___/
pdfgen_1     | 
pdfgen_1     | A Docker-powered stateless API for PDF files.
pdfgen_1     | Version: 7.5.0
pdfgen_1     | -------------------------------------------------------
pdfgen_1     | [SYSTEM] modules: api chromium gc libreoffice logging pdfcpu pdfengines pdftk prometheus qpdf uno uno-pdfengine webhook 
pdfgen_1     | [SYSTEM] gc: application started
pdfgen_1     | [SYSTEM] api: server listening on port 3000
pdfgen_1     | [SYSTEM] prometheus: collecting metrics
pdfgen_1     | [SYSTEM] pdfengines: pdfcpu pdftk qpdf uno-pdfengine
pdfgen_1     | [FATAL] starting uno: start long-running LibreOffice listener: waiting for the LibreOffice listener socket to be available: context deadline exceeded

Is this a timeout issue? I don't believe the previous docker image (7.4.3) had this issue.

We are currently using a Libreoffice + unoconv + api (node) architecture to generate our PDF, and we are considering switching to the more recent, maintained and beautifully coded Gotenberg ;) but we noticed some performance drawbacks.

The doc says It starts a dedicated LibreOffice instance for each request.. This seems to add about 2 to 3s to the generation time, vs. our current architecture where the Libreoffice instance is just constantly idling, waiting for a new request (unoconv in listener mode).

3 additional seconds per conversion feels quite like a long time =/ Is there any way to improve that? Do you envision an option in the future to keep the LibreOffice open for longer than one request?

Also, it says It starts a dedicated LibreOffice instance for each REQUEST but according to our preliminary tests, it seems like it does it for every conversion, not every request : if we make a request with multiple files to convert (and merge), the conversion time seems to just be linear with the number of docs (vs. our expectation of faster conversion for subsequent files once the LibreOffice instance is started for the first one). Do you confirm that's what is happening?

On the Live Demo, the unoconv listener process did become a zombie for some reason.

While unoconv is still working (it creates a dedicated LibreOffice instance in such a scenario), the conversions are way slower.

In order to prevent this from happening, we have to:

1. Check the state of the unoconv listener process.
2. If state is invalid (no such process / zombie), try to restart the listener.
3. If restart fails, /health endpoint should return an error.

I never programmed in Go before, so I don't clearly understand what I am doing.

This PR aims to add QPDF as a tool to merge PDFs, because it can deal with invalid PDFs files, which PDFtk can not do.

Also, I think that would be cool if Gotenberg have another tool on it.

Hi

Is there any way to support a proxy server for the chromium module? I have tried setting the system proxy, but that doesn't seem to do the trick. So there's still the --proxy-server flag for chromium but I guess that's not supported, is it?

When I send a significantly large payload of HTML (about 800kb) that contains a lot of images (say ~3-4 per page, 250 pages in total) - rendering fails with the following error message:

{
    "level": "error",
    "msg": "cdp.Page: PrintToPDF: rpc error: Printing failed (code = -32000)",
    "op": "xhttp.htmlHandler: xhttp.convertSync: printer.chromePrinter.Print",
    "time": "2020-09-22T18:04:50Z",
    "trace": "s1azQwaNSYBE6zK3y5R7VhstCYbPtrix"
}

and

{
    "level": "debug",
    "msg": "[0922/180450.372244:ERROR:print_render_frame_helper.cc(1889)] Printing failed.",
    "op": "stderr.google-chrome-stable.--no-sandbox.--headless.--disable-dev-shm-usage.--font-render-hinting=none.--remote-debugging-port=9222.--disable-gpu.--disable-translate.--disable-extensions.--disable-background-networking.--safebrowsing-disable-auto-update.--disable-sync.--disable-default-apps.--hide-scrollbars.--metrics-recording-only.--mute-audio.--no-first-run",
    "time": "2020-09-22T18:04:50Z",
    "trace": "system"
}

Is there anything I can do / tweak in the environment variables to mitigate this? I've already increased the RPC buffer without success. System is running on AWS Fargate, 2vCPUs, 8GB of RAM.

Expected Behavior

Rendered document is returned.

Current Behavior

Rendering fails with HTTP 500.

Your Environment

• Version used: 6.3.0
• Operating System and version: Docker container running on AWS Fargate 2/8GB

I noticed that sending the post request with file that has 150 344 bytes is slow. In my local enviroment I takes about 4 sec to get the Response. In my production enviroment I takes about 40 sec! We use python request library and we send just the attached file to the server. Do we need to use some extrat options to zip the html file or sth?

Hey there,

We're experiencing an issue with Gotenberg where by the memory usage is constantly increasing over time, up to a point that it is being killed by the container orchestrator, ECS in this instance. Here's a graph of gotenbergs memory usage over time.

The large drops are ECS killing the container when the memory limit is reached. (the last restart is a manual one by me) We've given the container 512MB of memory in this example.

Have you experienced this behaviour yourselves? Is 512MB sufficient? (We used 512MB as it is in the docs as a 'production' config) Is there a possible memory leak somewhere?

Many thanks in advance!

Your Environment

• Version used: 5.1.0
• Operating System and version: vendor provided docker image.

Hi @gulien Everything was fine with 7.4.0, but we just upgraded to 7.4.1 and when running the container with these parameters, we are getting this error :

docker run --rm -d -p xxxx:3000 --name gotenberg xxxxx/gotenberg gotenberg --chromium-disable-routes --pdfengines-disable-routes --webhook-disable --prometheus-disable-collect --prometheus-disable-route-logging

If we downgrade back to 7.4.0 it starts working again (iso parameters). Since the latest release is all about timeout, it seems like a big coincidence ^^

Is this meant btw? https://github.com/gotenberg/gotenberg/compare/v7.4.0...v7.4.1#diff-51bc8303a14a97d22bd6cf1de23da23a89d419b96fe2e37972552a0b4cec8f77R393

Trying to use this module in other a go mod enabled repo of us is causing issues with some of the unused dependencies (particularly delve). Running go mod tidy fixes these issues.

Expected Behavior

GO111MODULE=on go get -u github.com/thecodingmachine/[email protected] Should allow us to use the go module.

Current Behavior

The gotenberg module is marked as incompatible.

Possible Solution

run go mod tidy

Context

We are unable to use the go module for talking to the gotenberg service in our k8s cluster.

I have a commit ready on a fork. Wanted to raise an issue first, happy to raise PR if accepted.

I'm trying to figure out what the best way to add some form of support for ASIC-E files to paperless-ngx. ASIC-E is a signed container format - it's effectively a zip file that stores one or more documents and cryptographic signature metadata for the files. It's a standardized format, but mostly used in Estonia, where it is the default for any kind of contract or such that needs signing (electronic signatures are legally recognized and fairly common here). A simple way to support this format would be if the importer - using Gotenberg - could just transparently convert the document (or documents, though typically it is just one) inside of the asic-e zip archive.

Hi there,

When I attempt to convert a simple pptx file to pdf using the POST forms/libreoffice/convert endpoint in gotenberg I get a 500 error.
The pptx file that I am attempting to convert to pdf using the libre office engine is very simple. It has one slide with two images and a text label. I think the issue is related to the images used in the pptx but I'm not sure why they would cause the pdf conversion to fail. When I remove one of the images from the pptx the pdf conversion runs successfully.

See the below screen grab of the erroneous slide in the pptx. I have also attached the pptx that is causing the conversion failure

The following is a snippet of debug logs central to the issue. Full logs are here

{"level":"debug","ts":1654172407.363404,"logger":"api.formslibreofficeconvert.usrliblibreofficeprogramsoffice.bin","msg":"unix process already killed","trace":"656a0796-af74-4b8c-9acd-456409a7fff5"}
{"level":"error","ts":1654172407.3656774,"logger":"api","msg":"convert to PDF: unoconv PDF: unix process error: wait for unix process: exit status 6","trace":"6922e459-19b5-41e2-aff1-ab95297d3c4d","remote_ip":"10.1.18.135","host":"gotenberg-service:3000","uri":"/forms/libreoffice/convert","method":"POST","path":"/forms/libreoffice/convert","referer":"","user_agent":"Apache-HttpClient/4.5.13 (Java/11.0.10)","status":500,"latency":14209214897,"latency_human":"14.209214897s","bytes_in":775610,"bytes_out":21}
{"level":"debug","ts":1654172407.3685727,"logger":"api.formslibreofficeconvert.usrliblibreofficeprogramsoffice.bin","msg":"start unix process: /usr/lib/libreoffice/program/soffice.bin --headless --invisible --nocrashreport --nodefault --nologo --nofirststartwizard --norestore -env:UserInstallation=file:///tmp/bd7353dc-0119-4d19-aa82-308b96069ef8 --accept=socket,host=127.0.0.1,port=41679,tcpNoDelay=1;urp;StarOffice.ComponentContext","trace":"6922e459-19b5-41e2-aff1-ab95297d3c4d"}
{"level":"debug","ts":1654172409.1584835,"logger":"api.formslibreofficeconvert.usrliblibreofficeprogramsoffice.bin","msg":"unix process already killed","trace":"6922e459-19b5-41e2-aff1-ab95297d3c4d"}
{"level":"debug","ts":1654172409.1585321,"logger":"api.formslibreofficeconvert","msg":"got exit code 81, e.g., LibreOffice listener first start","trace":"6922e459-19b5-41e2-aff1-ab95297d3c4d"}

Docker file used to build Gotenberg image

FROM gotenberg/gotenberg:7.5.2
USER root
COPY /resources/fonts/* /usr/local/share/fonts/
USER gotenberg
CMD ["gotenberg", "--pdfengines-engines=uno-pdfengine", "--api-disable-health-check-logging=true", "--log-level=debug", "--api-timeout=60s"]

Any help with this would be much appreciated!

Thanks, Keith

The stateful mode LibreOffice conversion is nice because it is faster than stateless mode. I tried some performance tests by launching multiple instances (stateful mode) with a load balancer in the front.

Problem

The conversion queue size in Gotenberg looks unlimited. So Gotenberg will keep accepting a new request no matter how many pending conversion is.

End up the instances may:

• Be easily overloaded if there is a spike or unbalanced traffic
• Most of the requests will keep being timeout (loop in client side: timeout->retry->timeout->retry...)
• The overloaded instances cannot be recovered even scale up more instances after a while
• A possibility that Gotenberg started a conversion but the API request just timed out at the same time (wasted conversion)

Suggestion

It would be good if having an option to limit the queue size of LibreOffice stateful mode. And it will throttle/reject the new request immediately (avoid too many requests waiting for timeout) when there are a lot of pending conversions (based on libreoffice_listener_queue_length).

Then, client side can monitor easily and based on the rejected number to scale up more instances

Thanks and appreciated! 🙏

Discussed in https://github.com/gotenberg/gotenberg/discussions/456