[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27358: Timeout command was get failed to kill soffice.bin processes
From: |
Assaf Gordon |
Subject: |
bug#27358: Timeout command was get failed to kill soffice.bin processes |
Date: |
Wed, 14 Jun 2017 16:01:45 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hello Ken,
On Wed, Jun 14, 2017 at 03:58:19PM +0530, Ken Walker wrote:
[...] unoconv command
start soffice.bin proccess for convert file and it working fine to kill
that unoconv + soffice.bin process by timeout command if taken more than
time which define with timeout command, But sometime it was not killed
soffice.bin process so any idea why this happen?
[...]
exec('timeout 300 unoconv -T 10 -vvvvv -f csv -o "destination.xls"
"destination.csv" 2>&1', $arrOp, $return_value);
Few observation (though not a clear solution):
1. As you've mentioned, the unoconv program does not do the conversion
by itself, it needs a running openoffice program to do so (the
'soffice' binary).
2. If it doesn't find a running 'soffice' binary, it starts one.
But if there is already a running 'soffice' binary (which already
acts as a listener on 127.0.0.1:2002) - then it does NOT
start a new binary.
3. This means that the 'soffice' binary is not a child-process
of 'unoconv', and 'timeout' won't kill it.
you can observe the difference in the debug messages:
===
$ unoconv -vvvv -f csv -o 1.xls 1.csv
Verbosity set to level 4
Using office base path: /usr/lib/libreoffice
Using office binary path: /usr/lib/libreoffice/program
DEBUG: Connection type:
socket,host=127.0.0.1,port=2002;urp;StarOffice.ComponentContext
DEBUG: Existing listener not found.
DEBUG: Launching our own listener using
/usr/lib/libreoffice/program/soffice.bin.
LibreOffice listener successfully started. (pid=30564)
===
versus (when there's already an OpenOffice program running):
===
$ unoconv -vvvv -f csv -o 1.xls 1.csv
Verbosity set to level 4
Using office base path: /usr/lib/libreoffice
Using office binary path: /usr/lib/libreoffice/program
DEBUG: Connection type:
socket,host=127.0.0.1,port=2002;urp;StarOffice.ComponentContext
===
Without further details I can't tell if this is indeed the culprit
for the behaviour you're experiencing, but this would be one direction
to investigate.
As a side-note,
Since unoconv's operation model is based on a running OpenOffice
listener/server, it would be more efficient (IMHO)
to start one listener in the background, and then each 'unoconv'
invocation won't need to start a new OpenOffice instance (which is a
very slow process).
The unoconv program supports this operation mode with
the '--listener' and '--no-launch' parameters (see 'unoconv -h').
It would likely be useful to use a non-default port, to ensure
the listener does not conflict with other (non-listener) open-office
instances.
HTH,
- assaf