Description: In the Amazon AWS Lambda environment, we are doing document conversion with LibreOffice and Node.js. However, after we perform the conversion with LibreOffice, there are zombie processes left behind. They are "soffice.bin", "gpg2", and "gpgconf". In our case, there is no init process, only Node.js (which is running as PID 1) and it does not reap zombies. Therefore, as we continue to convert documents, the number of zombie processes increases linearly until we hit Lambda's process limit. The command is run synchronously and correctly waits for the main process to finish before returning, but it looks like LO is not cleaning up as it should. LibreOffice should not leave behind these zombie processes. The conversion command: ./instdir/program/soffice --headless --invisible --nodefault --nofirststartwizard --nolockcheck --nologo --norestore --convert-to pdf --outdir somePath someDocFile.docx Running "ps aux": 484 86 0.0 0.0 0 0 ? Z 16:06 0:00 [soffice.bin] <defunct> 484 124 0.0 0.0 0 0 ? Z 16:06 0:00 [gpgconf] <defunct> 484 126 0.0 0.0 0 0 ? Z 16:06 0:00 [gpgconf] <defunct> 484 128 0.0 0.0 0 0 ? Z 16:06 0:00 [gpg2] <defunct> 484 130 0.0 0.0 0 0 ? Z 16:06 0:00 [soffice.bin] <defunct> 484 132 0.0 0.0 0 0 ? Z 16:06 0:00 [gpgconf] <defunct> 484 175 0.0 0.0 0 0 ? Z 16:06 0:00 [gpgconf] <defunct> 484 177 0.0 0.0 0 0 ? Z 16:06 0:00 [gpgconf] <defunct> 484 179 0.0 0.0 0 0 ? Z 16:06 0:00 [gpg2] <defunct> 484 181 0.0 0.0 0 0 ? Z 16:06 0:00 [soffice.bin] <defunct> 484 183 0.0 0.0 0 0 ? Z 16:06 0:00 [gpgconf] <defunct> 484 307 0.0 0.0 0 0 ? Z 16:08 0:00 [gpgconf] <defunct> 484 309 0.0 0.0 0 0 ? Z 16:08 0:00 [gpgconf] <defunct> 484 311 0.0 0.0 0 0 ? Z 16:08 0:00 [gpg2] <defunct> 484 313 0.0 0.0 0 0 ? Z 16:08 0:00 [soffice.bin] <defunct> 484 315 0.0 0.0 0 0 ? Z 16:08 0:00 [gpgconf] <defunct> 484 375 0.0 0.0 0 0 ? Z 16:09 0:00 [gpgconf] <defunct> 484 377 0.0 0.0 0 0 ? Z 16:09 0:00 [gpgconf] <defunct> 484 379 0.0 0.0 0 0 ? Z 16:09 0:00 [gpg2] <defunct> 484 381 0.0 0.0 0 0 ? Z 16:09 0:00 [soffice.bin] <defunct> 484 383 0.0 0.0 0 0 ? Z 16:09 0:00 [gpgconf] <defunct> 484 484 0.0 0.0 0 0 ? Z 16:11 0:00 [gpgconf] <defunct> 484 486 0.0 0.0 0 0 ? Z 16:11 0:00 [gpgconf] <defunct> 484 488 0.0 0.0 0 0 ? Z 16:11 0:00 [gpg2] <defunct> 484 490 0.0 0.0 0 0 ? Z 16:11 0:00 [soffice.bin] <defunct> 484 492 0.0 0.0 0 0 ? Z 16:11 0:00 [gpgconf] <defunct> 484 549 0.0 0.0 0 0 ? Z 16:11 0:00 [gpgconf] <defunct> 484 551 0.0 0.0 0 0 ? Z 16:11 0:00 [gpgconf] <defunct> 484 553 0.0 0.0 0 0 ? Z 16:11 0:00 [gpg2] <defunct> 484 555 0.0 0.0 0 0 ? Z 16:11 0:00 [soffice.bin] <defunct> 484 557 0.0 0.0 0 0 ? Z 16:11 0:00 [gpgconf] <defunct> 484 600 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 602 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 604 0.0 0.0 0 0 ? Z 16:12 0:00 [gpg2] <defunct> 484 606 0.0 0.0 0 0 ? Z 16:12 0:00 [soffice.bin] <defunct> 484 608 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 641 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 643 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 645 0.0 0.0 0 0 ? Z 16:12 0:00 [gpg2] <defunct> 484 647 0.0 0.0 0 0 ? Z 16:12 0:00 [soffice.bin] <defunct> 484 649 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 686 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 688 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 690 0.0 0.0 0 0 ? Z 16:12 0:00 [gpg2] <defunct> 484 692 0.0 0.0 0 0 ? Z 16:12 0:00 [soffice.bin] <defunct> 484 694 0.0 0.0 0 0 ? Z 16:12 0:00 [gpgconf] <defunct> 484 733 0.0 0.0 0 0 ? Z 16:13 0:00 [gpgconf] <defunct> 484 735 0.0 0.0 0 0 ? Z 16:13 0:00 [gpgconf] <defunct> 484 737 0.0 0.0 0 0 ? Z 16:13 0:00 [gpg2] <defunct> 484 739 0.0 0.0 0 0 ? Z 16:13 0:00 [soffice.bin] <defunct> 484 741 0.0 0.0 0 0 ? Z 16:13 0:00 [gpgconf] <defunct> 484 888 0.0 0.0 0 0 ? Z 16:15 0:00 [gpgconf] <defunct> 484 890 0.0 0.0 0 0 ? Z 16:15 0:00 [gpgconf] <defunct> 484 892 0.0 0.0 0 0 ? Z 16:15 0:00 [gpg2] <defunct> 484 894 0.0 0.0 0 0 ? Z 16:15 0:00 [soffice.bin] <defunct> 484 896 0.0 0.0 0 0 ? Z 16:15 0:00 [gpgconf] <defunct> 484 1010 0.0 0.0 0 0 ? Z 16:16 0:00 [gpgconf] <defunct> 484 1012 0.0 0.0 0 0 ? Z 16:16 0:00 [gpgconf] <defunct> 484 1014 0.0 0.0 0 0 ? Z 16:16 0:00 [gpg2] <defunct> 484 1016 0.0 0.0 0 0 ? Z 16:16 0:00 [soffice.bin] <defunct> 484 1018 0.0 0.0 0 0 ? Z 16:16 0:00 [gpgconf] <defunct> 484 1061 0.0 0.0 0 0 ? Z 16:17 0:00 [gpgconf] <defunct> 484 1063 0.0 0.0 0 0 ? Z 16:17 0:00 [gpgconf] <defunct> 484 1065 0.0 0.0 0 0 ? Z 16:17 0:00 [gpg2] <defunct> 484 1067 0.0 0.0 0 0 ? Z 16:17 0:00 [soffice.bin] <defunct> 484 1069 0.0 0.0 0 0 ? Z 16:17 0:00 [gpgconf] <defunct> 484 1077 0.0 0.0 117216 2376 ? R 16:17 0:00 ps aux This is reproducable on the 6.0 branch circa April 30. Steps to Reproduce: 1. Create an environment where there is no init to reap defunct processes 2. Run LibreOffice in headless mode (e.g. converting a document to PDF) 3. Observe that zombie processes remain afterward Actual Results: "soffice.bin", "gpg2", and "gpgconf" processes remain in defunct status Expected Results: No zombie processes left after conversion finished Reproducible: Always User Profile Reset: Yes Additional Info: This is a continuation of an error described in a comment on another bug. I am opening this on behalf of the user "g4827387". https://bugs.documentfoundation.org/show_bug.cgi?id=95843#c20 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Hi there, We have the same problem with LibreOffice_6.1.0 on a Linux machine with 4.4.0-1062-aws kernel version. Everytime we run `libreoffice6.1/program/soffice.bin --headless --invisible --nocrashreport --nodefault --nofirststartwizard --nologo --norestore --accept=socket,host=12` we end up with zombie processes. Cheers, Claudiu
Let's consider this confirmed then
So there was a change for 6.1.1 IIRC, this commit here: https://gerrit.libreoffice.org/58363 Which should avoid any running of xmlsecurity / X509 / GnuPG code, _unless_ the document contains digital signatures. So that would be the first thing that needs checking (version of libreoffice _actually_ running, and if one of the documents has signatures) The ps trace itself is not telling much, perhaps ps aux --forest might - still I don't see the problem, so can't do much about it. One theory: gpg2 waits for another service, keyserver or whatnot, and that is blocked or filtered. Still, that should eventually timeout. Or is there some SELinux or other advanced syscall filtering (e.g. containers) going on?
> The ps trace itself is not telling much, perhaps ps aux --forest might - > still I don't see the problem, so can't do much about it. @diskdefrag, @Claudiu Olteanu, would you mind sharing with us the result from ps aux --forest ? OTOH, is the issue still reproducible with LibreOffice 6.1.2.1 ? Setting to NEEDINFO until the information requested above has been provided
Hi there, Sorry for the delay but I didn't have access to my laptop in the previous week. Here is the output for `ps -aux --forest` of LibreOffice 6.1.0.3 efb621ed25068d70781dc026f7e9c5187a4decd1 version: ># ps -aux --forest USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 86 0.0 0.0 22684 4088 pts/0 Ss 07:24 0:00 /bin/bash root 1975 0.0 0.0 19884 2572 pts/0 R+ 07:27 0:00 \_ ps -aux --forest root 1 0.9 0.3 1333924 113892 ? Ssl 07:24 0:01 python exporter.py root 1823 0.0 0.0 0 0 ? Z 07:27 0:00 [soffice.bin] <defunct> root 1949 2.0 0.0 0 0 ? Z 07:35 0:00 [gpg] <defunct> After we updated the packages to LibreOffice 6.1.2.1 65905a128db06ba48db947242809d14d3f9a93fe it seems that there are no more `gpg` zombie processes after each pptx to pdf exporting task. To give you more context, we have an exporting service that runs into a container and it represents the entrypoint (*python exporter.py* from the previous output). If you need more details about how we are running the containers, please let me know. Cheers, Claudiu
So it's fixed for 6.1.2.1 ?
Yes, it seems that in 6.1.2.1 version there are no more GPG zombie processes. However, the `soffice.bin` zombie process remains.
We are in the process of upgrading our LibreOffice build to version 6.1.3.1. In our limited testing, it seems that the zombie process issue has been resolved (no zombies left whatsoever).
(In reply to diskdefrag from comment #8) > We are in the process of upgrading our LibreOffice build to version 6.1.3.1. > In our limited testing, it seems that the zombie process issue has been > resolved (no zombies left whatsoever). Good to hear. JFYI, 6.1.3.2 will be released in a week from now, 6.1.3.1 is a Release Candidate. Maybe you prefer to wait a bit longer if you have to upgrade many stations...
Closing as 6.0 is EOL and this is fixed in 6.1.