[Bug]: ocrmypdf is called in DEBUG logging mode (by default?)

[mediowen]

Installation Method

Docker

The Problem

Despite using Stirling PDF's default logging levels, I'm finding that ocrmypdf outputs DEBUG logs at INFO level for stirling.software.common.utils.ProcessExecutor. This makes my logging exceptionally verbose.

An example: 12:15:21.799 [Thread-325] INFO s.s.common.util.ProcessExecutor - DEBUG ocrmypdf.optimize - xref 786: found image compressed as /FlateDecode /DCTDecode, marked for JPEG optimization

As a workaround for now, I've mounted /configs/custom_settings.yml with the following:

logging:
  level:
    stirling.software.common.util.ProcessExecutor: WARN

This gets rid of the noise problem, but does leave me flying somewhat blind compared to default config.

Version of Stirling-PDF

1.3.2

Last Working Version of Stirling-PDF

No response

Page Where the Problem Occurred

No response

Docker Configuration

Relevant Log Output

12:15:21.799 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf.optimize - xref 786: found image compressed as /FlateDecode /DCTDecode, marked for JPEG optimization
12:15:21.799 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf.optimize - xref 787: found image compressed as /FlateDecode /DCTDecode, marked for JPEG optimization
12:15:21.800 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf.optimize - xref 789: found image compressed as /FlateDecode /DCTDecode, marked for JPEG optimization
12:15:21.801 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf.optimize - xref 790: found image compressed as /FlateDecode /DCTDecode, marked for JPEG optimization
12:15:21.801 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf.optimize - Optimizable images: JBIG2 groups: 0
12:15:21.802 [Thread-325] INFO  s.s.common.util.ProcessExecutor -
12:15:22.064 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf.helpers - os.symlink(/tmp/stirling-pdf/ocrmypdf.io.y12wb6go/optimize.opt.pdf, /tmp/stirling-pdf/ocrmypdf.io.y12wb6go/optimize.pdf)
12:15:22.073 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf.subprocess - Running: ['jbig2', '--version']
12:15:22.077 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf.subprocess - Running: ['pngquant', '--version']
12:15:22.080 [Thread-325] INFO  s.s.common.util.ProcessExecutor -    INFO ocrmypdf._pipeline - Image optimization ratio: 1.40 savings: 28.5%
12:15:22.080 [Thread-325] INFO  s.s.common.util.ProcessExecutor -    INFO ocrmypdf._pipeline - Total file size ratio: 1.38 savings: 27.7%
12:15:22.081 [Thread-325] INFO  s.s.common.util.ProcessExecutor -   DEBUG ocrmypdf._pipeline - /tmp/stirling-pdf/ocrmypdf.io.y12wb6go/optimize.pdf -> /tmp/stirling-pdf/stirling-pdf/stirling-pdf-15718575462751683650.pdf
12:15:53.171 [qtp298295476-26] INFO  s.s.S.c.api.misc.OCRController - OCRmyPDF processing completed successfully

Additional Information

No response

Browsers Affected

No response

No Duplicate of the Issue

• [x] I have verified that there are no existing issues raised related to my problem.

[dosubot[bot]]

Hi @mediowen! I'm Dosu and I’m helping the Stirling-PDF team.

The verbose ocrmypdf DEBUG logs appear at INFO level in Stirling-PDF because the ProcessExecutor component logs all subprocess output at INFO, regardless of the actual log level in the subprocess output. There isn't a built-in way to filter or remap these logs by their content—so your workaround of raising the ProcessExecutor log level to WARN is currently the only way to suppress the noise, but it does mean you lose all normal logs from that component as well.

There are no documented options in Stirling-PDF to control ocrmypdf's log verbosity directly from the application side; the available configuration focuses on Java-side logging levels via /configs/custom_settings.yml or environment variables in Docker deployments. For reference, see the logging configuration docs.

If ocrmypdf itself supports CLI flags or environment variables to reduce its verbosity, you could try customizing the command invocation, but currently, Stirling-PDF does not expose a way to do this through its configuration.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}