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
Apparently, this is linked to the command line options syntax change, this does not happen with "--env" instead of "-env"
(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.
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.
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.
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.
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.
(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.
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)