[Upstream] Headless soffice failure condition

[Mathieu GUILLAUME]

Command line executed:
"/usr/lib/libreoffice/program/soffice.bin" "-accept=socket,host=127.0.0.1,port=2003,tcpNoDelay=1;urp;" "-env:UserInstallation=file:///tmp/.jodconverter_socket_host-127.0.0.1_port-2003" "-headless" "-nocrashreport" "-nodefault" "-nofirststartwizard" "-nolockcheck" "-nologo" "-norestore"

This will return on the first run. The soffice process doesn't stick around.
This will work on subsequent runs (process doesn't return).
If the "env:UserInstallation" (/tmp/.jodconverter_socket_host-127.0.0.1_port-2003) directory is removed, it will fail again at the next execution.

A LibreOffice 3.4 package on Windows doesn't show the same behaviour (works every time), though it may not be the same build of LibreOffice 3.4.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: libreoffice 1:3.4.4-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-13.22-generic 3.0.6
Uname: Linux 3.0.0-13-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Fri Dec 9 22:01:41 2011
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100323)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: libreoffice
UpgradeStatus: Upgraded to oneiric on 2011-05-16 (207 days ago)

[Mathieu GUILLAUME (mg-nuxeo)]

Duplicated on another oneiric machine.

[panticz.de (panticz.de)]

Hi,

with libs did you use? After i upgrade jars in my java classpath to:

/usr/share/java/juh.jar
/usr/share/java/ridl.jar
/usr/share/java/jurt.jar
/usr/share/libreoffice/basis3.4/program/classes/officebean.jar
/usr/share/libreoffice/basis3.4/program/classes/unoil.jar

my java application works again. Commandline:
/usr/lib/libreoffice/program/soffice.bin "--accept=socket,host=127.0.0.1,port=8100;urp;" --headless --nodefault --nolockcheck --nologo --norestore

(Tested on Ubuntu 11.10, LibreOffice 3.4.4)

BR

panticz

[Mathieu GUILLAUME (mg-nuxeo)]

I haven't played with the classpath (there shouldn't be any reason to, I'm calling soffice.bin as an independent process).

The issue here definetly seems to be with the initial profile setup in the "env:UserInstallation" location, as the issue is reproductible with just this command:
/usr/lib/libreoffice/program/soffice.bin -env:UserInstallation=file:///tmp/lotest

[Mathieu GUILLAUME (mg-nuxeo)]

Seems to be linked to the resync of ${UserInstallation}/user/extensions/bundled

[Mathieu GUILLAUME (mg-nuxeo)]

The first time LibreOffice is started with a custom UserInstallation, it will stop after a few seconds.

How to reproduce:
Run: /usr/lib/libreoffice/program/soffice.bin -env:UserInstallation=file:///tmp/lotest
Result: returns after a few seconds, no soffice process remaining
Run the same command again: OK, doesn't exit by itself
Remove /tmp/lotest and try again: KO, exits by itself

This has been reproduced on Ubuntu 11.10 with LibreOffice 3.4 and Ubuntu 12.04 beta1 with LibreOffice 3.5.1.
When I tested on Windows with a 3.4 distribution, this didn't happen, not sure if this is specific to the ubuntu packaging or general to linux.

Related tickets:
- Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/902344
- Nuxeo: https://jira.nuxeo.com/browse/NXP-8118

[Mathieu GUILLAUME (mg-nuxeo)]

The first time LibreOffice is started with a custom UserInstallation, it will stop after a few seconds.

How to reproduce:
Run: /usr/lib/libreoffice/program/soffice.bin -env:UserInstallation=file:///tmp/lotest
Result: returns after a few seconds, no soffice process remaining
Run the same command again: OK, doesn't exit by itself
Remove /tmp/lotest and try again: KO, exits by itself

This has been reproduced on Ubuntu 11.10 with LibreOffice 3.4 and Ubuntu 12.04 beta1 with LibreOffice 3.5.1.
When I tested on Windows with a 3.4 distribution, this didn't happen, not sure if this is specific to the ubuntu packaging or general to linux.

Related tickets:
- Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/902344
- Nuxeo: https://jira.nuxeo.com/browse/NXP-8118

[Mathieu GUILLAUME (mg-nuxeo)]

Apparently, this is linked to the command line options syntax change, this does not happen with "--env" instead of "-env"

[Sbergman (sbergman)]

(In reply to comment #1)
> Apparently, this is linked to the command line options syntax change, this does
> not happen with "--env" instead of "-env"

No, UNO bootstrap variables (like that "UserInstallation") are still passed via -env, not --env (unless Debian and/or Ubuntu broke that in their specific LO instances, which I doubt). What happens in LO 3.5 if you pass --env:... is that that argument is effectively ignored (so that it will use the default user installation in the above case); LO 3.6 will give an error about an unknown option.

[Mathieu GUILLAUME (mg-nuxeo)]

The crash happens during the loading of extensions.
If I use the LibreOffice-provided .debs and don't install any of the "libobasis3.5-extension-*" packages, the crash doesn't happen.
This doesn't seem to be possible with the Ubuntu packaging however.

Is there a command-line option to start without loading any extension? I couldn't find one.

[Mathieu GUILLAUME (mg-nuxeo)]

Apparently, this is linked to the command line options syntax change, this does not happen with "--env" instead of "-env"

[Sbergman (sbergman)]

(In reply to comment #1)
> Apparently, this is linked to the command line options syntax change, this does
> not happen with "--env" instead of "-env"

No, UNO bootstrap variables (like that "UserInstallation") are still passed via -env, not --env (unless Debian and/or Ubuntu broke that in their specific LO instances, which I doubt). What happens in LO 3.5 if you pass --env:... is that that argument is effectively ignored (so that it will use the default user installation in the above case); LO 3.6 will give an error about an unknown option.

[Mathieu GUILLAUME (mg-nuxeo)]

I managed to skip loading the bundled extensions by creating an empty dir (say /tmp/empty) and adding this to the command line: -env:BUNDLED_EXTENSIONS=file:///tmp/empty

This solves my problem, but the bug still exists.

[Thierry Delprat (tdelprat)]

I confirm I have the exact same issue running 12.04 beta2 with LibreOffice 3.5.1.2.
The sad part being that based on what I can see in the forums using -env is the only solution, but it does not work ...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mathieu GUILLAUME (mg-nuxeo)]

The crash happens during the loading of extensions.
If I use the LibreOffice-provided .debs and don't install any of the "libobasis3.5-extension-*" packages, the crash doesn't happen.
This doesn't seem to be possible with the Ubuntu packaging however.

Is there a command-line option to start without loading any extension? I couldn't find one.

[Mathieu GUILLAUME (mg-nuxeo)]

I managed to skip loading the bundled extensions by creating an empty dir (say /tmp/empty) and adding this to the command line: -env:BUNDLED_EXTENSIONS=file:///tmp/empty

This solves my problem, but the bug still exists.

[Mathieu GUILLAUME (mg-nuxeo)]

Bug reported upstream: https://bugs.freedesktop.org/show_bug.cgi?id=48341

[Sbergman (sbergman)]

Ah, re-reading your original description now, notice that you start soffice.bin instead of soffice. And it is not crashing, it is just that if soffice.bin detects that there were changes to bundled or shared extensions not yet reflected in the per-user configuration data (which is esp. the case if the per-user configuration data is freshly generated, as in your case), it does the necessary steps to sync that extension information and then exits with a special code (81), so that the wrapping process (on Linux oosplash, in turn spawned by the soffice script) restarts soffice.bin automatically.

You must always start soffice, not soffice.bin.

[Jim-libreoffice (jim-libreoffice)]

Starting with the soffice script in a daemon on linux isn't feasible because it doesn't give the starting process any way to kill the real soffice.bin process.
On Windows killing the parent process kills soffice.bin, but on linux one ends up with a bunch of zombie soffice.bin processes.

If it isn't possible to start soffice.bin directly, please can we have a reliable way to kill the soffice.bin process (a file with the PIDs for both soffice.bin and oosplash would be adequate).
Note that this is needed in the case where soffice.bin is no longer responding, so using the API is not an option.

Interestingly I've only started being hit by this problem with LibO_3.5.3rc2_Linux_x86-64, on a different virtual machine I am using LibO_3.5.1rc2_Linux_x86-64 and it is working correctly.

[Sbergman (sbergman)]

(In reply to comment #6)
> If it isn't possible to start soffice.bin directly, please can we have a
> reliable way to kill the soffice.bin process (a file with the PIDs for both
> soffice.bin and oosplash would be adequate).
> Note that this is needed in the case where soffice.bin is no longer responding,
> so using the API is not an option.

See <http://lists.freedesktop.org/archives/libreoffice/2012-April/030424.html> "[REVIEW][3-5] misc stuff" for thoughts on that (and how it currently already works on master, unreliably, but maybe fine for your taste).

In any event, that RFE should better go into a bug of its own, so please close this bug again as NOTABUG.

[Jim-libreoffice (jim-libreoffice)]

Bug filed as https://bugs.freedesktop.org/show_bug.cgi?id=49432

Given that this behaviour is a regression I think it is a bug (it's stopping me from using 3.5.3)

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.