bug#27358: Timeout command was get failed to kill soffice.bin processes

[Assaf Gordon]

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