GNU bug report logs - #27358
Timeout command was get failed to kill soffice.bin processes

Previous Next

Package: coreutils;

Reported by: Ken Walker <kenwalker833 <at> gmail.com>

Date: Wed, 14 Jun 2017 15:26:01 UTC

Severity: normal

Tags: notabug

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 27358 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Ken Walker <kenwalker833 <at> gmail.com>
Cc: 27358 <at> debbugs.gnu.org
Subject: Re: bug#27358: Timeout command was get failed to kill soffice.bin
 processes
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




This bug report was last modified 6 years and 259 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.