Bug 48341 - LibreOffice fails to start with a virgin UserInstallation
Summary: LibreOffice fails to start with a virgin UserInstallation
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-05 08:48 UTC by Mathieu Guillaume
Modified: 2012-05-03 08:29 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Guillaume 2012-04-05 08:48:00 UTC
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
Comment 1 Mathieu Guillaume 2012-04-10 05:31:34 UTC
Apparently, this is linked to the command line options syntax change, this does not happen with "--env" instead of "-env"
Comment 2 Stephan Bergmann 2012-04-10 06:04:39 UTC
(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.
Comment 3 Mathieu Guillaume 2012-04-10 08:58:34 UTC
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.
Comment 4 Mathieu Guillaume 2012-04-10 13:43:27 UTC
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.
Comment 5 Stephan Bergmann 2012-05-03 02:51:44 UTC
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.
Comment 6 jim-libreoffice 2012-05-03 06:14:35 UTC
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.
Comment 7 Stephan Bergmann 2012-05-03 06:31:01 UTC
(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.
Comment 8 jim-libreoffice 2012-05-03 08:29:27 UTC
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)