Description: When converting documents to PDF in headless mode, if you run 2 conversions concurrently one does not produce any output. Steps to Reproduce: 1. In one terminal window enter libreoffice6.1 --convert-to pdf hamlet1.docx 2. In second terminal window, before 1st conversions completes libreoffice6.1 --convert-to pdf hamlet2.docx 3. Check for output (hamlet1.pdf and hamlet2.pdf) Actual Results: neily@dev6 tmp 13:45:44 2008 $ time libreoffice6.1 --convert-to pdf /tmp/hamlet1.docx convert /tmp/hamlet1.docx -> /tmp/hamlet1.pdf using filter : writer_pdf_Export Overwriting: /tmp/hamlet1.pdf real 0m2.948s user 0m2.822s neily@dev6 tmp 13:45:34 1970 $ time libreoffice6.1 --convert-to pdf /tmp/hamlet2.docx real 0m2.233s user 0m0.011s sys 0m0.001s Note that the expected message "convert /tmp/hamlet1.docx -> /tmp/hamlet1.pdf using filter : writer_pdf_Export" does not appear in the second result neily@dev6 tmp 13:44:42 2006 $ ls -l *.pdf -rw-rw-r-- 1 neily neily 279359 Oct 18 13:44 hamlet1.pdf Note: hamlet2.pdf is not present Expected Results: 2 PDF files should have been produced. Reproducible: Always User Profile Reset: No Additional Info: the workaround of using -env:UserInstallation=file:///tmp/unique-dir/ from Bug 113259 seems to be effective for this issue as well.
This is not a bug per se: the first started instance grabs the profile, which causes all subsequent instances (launched during the first session run) to try to connect to the first session and ask it to process their request. But the first instance is launched with a single --convert-to parameter, so it doesn't process others' requests, but just finishes its job and quits. A workaround could be to launch the worker instance in advance, without any --convert-to switches, so that it would run in the background and wait for other instances' requests. Then it would work. This has an additional benefit of greater performance (no overhead of initializing LO for every launched process). Another way would be to guarantee that the first instance is finished before launching the next (no concurrent runs). But of course, this is a valid enhancement request, to allow signalling to secondary instances that their request is refused so that they could wait until the primary instance is finished, and do that themselves (with the risk of waiting indefinitely for the primary instance in case it hangs for some unrelated reason, then behaving similarly to bug 38915).
Saying that a failure to perform a requested function is not a bug seems to be taking "it's a feature not a bug" jokes a little too far. It seems to be an unintended consequence of other design decisions and, at the very least, it's a violation of the principle of least surprise. As someone who is not familiar with the architecture of LibreOffice, it's not obvious that if I request a standalone conversion that it would/should connect to a prior instance and ask that to perform the operation. Similarly I would not necessarily expect such a job to perform operations for other instances and continue running until there are no more client instances expecting it to run jobs for them. As a practical solution for my immediate needs I believe the workaround I have will allow me to run independent jobs in parallel. Conceptually it seems to me that the headless option needs to be split into 2 different options, a headless server and a standalone one-shot operation.
https://gerrit.libreoffice.org/65610 The proposed change would allow to detect failures by checking the process exit code (currently it returns 0, as if everything went fine).
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b1491ff14a22639775dd8b8ca130258a1b95421b%5E%21 tdf#120676: don't send "processing done" when refused to process It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I installed a daily build from libreoffice-6-2~2019-01-01_21.34.24_LibreOfficeDev_6.2.0.1.0_Linux_x86-64_deb.tar.gz and I can see no difference.
(In reply to Neil Youngman from comment #5) > I installed a daily build from > libreoffice-6-2~2019-01-01_21.34.24_LibreOfficeDev_6.2.0.1.0_Linux_x86- > 64_deb.tar.gz and I can see no difference. I've found the right daily build now and it seems to wait until the first conversion finishes before starting the second.