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

From: Assaf Gordon <[email-masked]>
Date: Wed, 14 Jun 2017 16:01:45 +0000

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