Bug 834800 - [fix available] general error occurred while accessing your central configuration, when DATA env var set
[fix available] general error occurred while accessing your central configura...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libreoffice (Show other bugs)
6.2
x86_64 Linux
unspecified Severity urgent
: rc
: ---
Assigned To: Stephan Bergmann
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-23 14:15 EDT by Brian Fristensky
Modified: 2012-07-10 06:53 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-10 03:56:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of error message (11.42 KB, image/png)
2012-06-23 14:15 EDT, Brian Fristensky
no flags Details
contains .libreoffice directory, newly created when trying to start LO (962 bytes, application/x-bzip2)
2012-06-24 10:51 EDT, Brian Fristensky
no flags Details
strace from trying to start libreoffice (599.84 KB, text/plain)
2012-06-24 11:00 EDT, Brian Fristensky
no flags Details
output from rpm -qa|grep libreoffice > rpm.out (562 bytes, text/plain)
2012-06-24 22:39 EDT, Brian Fristensky
no flags Details
output from rpm -V `rpm -qa|grep libreoffice|xargs` > rpmV.out (2.56 KB, text/plain)
2012-06-24 22:41 EDT, Brian Fristensky
no flags Details
screen messages from rpm -V `rpm -qa|grep libreoffice|xargs` > rpmV.out (2.92 KB, text/plain)
2012-06-24 22:42 EDT, Brian Fristensky
no flags Details
strace using original .openoffice.org (670.48 KB, text/plain)
2012-06-24 23:18 EDT, Brian Fristensky
no flags Details
output from set when LO fails to launch (8.26 KB, text/plain)
2012-07-09 22:13 EDT, Brian Fristensky
no flags Details
output from set when LO works (6.07 KB, text/plain)
2012-07-09 22:15 EDT, Brian Fristensky
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 42961 None None None 2012-07-10 03:51:19 EDT
FreeDesktop.org 49188 None None None 2012-06-24 15:46:57 EDT
OpenOffice.org 118239 None None None 2012-06-28 08:56:16 EDT
Launchpad 792947 None None None 2012-06-24 15:48:29 EDT
Debian BTS 633929 None None None 2012-06-24 15:48:48 EDT

  None (edit)
Description Brian Fristensky 2012-06-23 14:15:19 EDT
Created attachment 593922 [details]
screenshot of error message

Description of problem: 
Today I upgraded my RHEL6.2 system using System --> Administration --> Software update. Apparently, the update deleted OpenOffice and replaced it with Libreoffice.
I rebooted after the upgrade. 
All attempts to launch LibreOffice result in a failure to launch any LO component.

Version-Release number of selected component (if applicable): 
LO3.4


How reproducible:
Somewhat reproducible. This happened to me after I installed Libreoffice 3.3 on Fedora 13, which caused me to upgrade to RHEL6 when no fix seemed to be available. It has been reported extensively on the Internet, for both Windows and Linux, but there is still no certain fix to the problem. Apparently, it doesn't happen to everyone, but happens frequently enough that the same problem has been reported many times since 2011.


Steps to Reproduce:
1. Applications --> Office --> Libreoffice Writer (or Calc or Impress or Draw)

  
Actual results:

Try to launch any LO component from either the command line or the Applications menu always fails to launch.  The splash screen appears, and only a tiny bit of the progress bar in the splash screen fills in, from left to right. Almost immediately, a window pops up with the message:

The application cannot be started. 
A general error occurred while accessing your central configuration. 

Alternatively, launching from the command line using 'oowriter' 'oocalc' etc. give the same result. No error messages appear in the terminal window. Only the popup error is seen.

Expected results: 
Libreoffice components launch


Additional info:

Some of the reports on various newsgroups suggest deleting .openoffice and .libreoffice directories, and it appeared to work for some users, but not for
others.
I have tried renaming my openoffice.org directory, and deleting the newly-created .libreoffice directory, but that doesn't fix the problem.
Comment 2 Caolan McNamara 2012-06-23 18:32:18 EDT
a) If you've seen the bug reported elsewhere, has the bug been reported to any other bugzilla anywhere ?, i.e not a random web forum, but any existing bugs.freedesktop.org, bugzilla.redhat.com (was there any reports of this around F-13, I've no memory of any?) or somesuch location ?

b) can I get the output of...
unopkg list && unopkg list --shared && unopkg list --bundled

c) Can you try tar cjf .libreoffice .openoffice.org /tmp/config.tar.bz2 and attach /tmp/config.tar.bz2 to this bug issue. Though that seems a longshot given that you already seem to have tried deleting those ?

d) The output of 
strace -f /usr/lib/libreoffice/program/soffice.bin > /tmp/strace.log 2>&1
and attaching /tmp/strace.log to this bug might help as well.
Comment 3 Brian Fristensky 2012-06-24 10:42:20 EDT
Re: a)

First, thanks for a very rapid response to my bug post!

At the very top of the list is a bug report I posted to the OpenOffice bugzilla. It is currently marked as closed, I suppose, because it never got solved and there has no further activity on it:

https://issues.apache.org/ooo/show_bug.cgi?id=118239

Some additional reports that look informative:

http://lists.freedesktop.org/archives/libreoffice-bugs/2012-April/049778.html

http://lists.debian.org/debian-openoffice/2012/04/msg00154.html

http://us.generation-nt.com/bug-633929-also-seeing-bug-help-207050472.html


http://ubuntuforums.org/showthread.php?t=1861643

https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/792947

http://user.services.openoffice.org/en/forum/viewtopic.php?f=6&t=33374

I will send in formation regarding your question s b, c and d in separate comments
Comment 4 Brian Fristensky 2012-06-24 10:43:55 EDT
Re: b)

>unopkg list && unopkg list --shared && unopkg list --bundled

ERROR: Cannot determine language!

unopkg failed.
terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException'
/usr/lib64/libreoffice/program/unopkg: line 141: 31585 Aborted                 (core dumped) "$sd_prog/unopkg.bin" "$@" "$JVMFWKPARAMS" "-env:INIFILENAME=vnd.sun.star.pathname:$sd_prog/redirectrc"

ERROR: Cannot determine language!

unopkg failed.
terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException'
/usr/lib64/libreoffice/program/unopkg: line 141: 31662 Aborted                 (core dumped) "$sd_prog/unopkg.bin" "$@" "$JVMFWKPARAMS" "-env:INIFILENAME=vnd.sun.star.pathname:$sd_prog/redirectrc"

ERROR: Cannot determine language!

unopkg failed.
terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException'
/usr/lib64/libreoffice/program/unopkg: line 141: 31730 Aborted                 (core dumped) "$sd_prog/unopkg.bin" "$@" "$JVMFWKPARAMS" "-env:INIFILENAME=vnd.sun.star.pathname:$sd_prog/redirectrc"
Comment 5 Brian Fristensky 2012-06-24 10:51:14 EDT
Created attachment 594011 [details]
contains .libreoffice directory, newly created when trying to start LO
Comment 6 Brian Fristensky 2012-06-24 11:00:18 EDT
Created attachment 594012 [details]
strace from trying to start libreoffice

strace -f /usr/lib64/libreoffice/program/soffice.bin > /tmp/strace.log 2>&1
Comment 7 Caolan McNamara 2012-06-24 16:13:26 EDT
hmm, that .config is *way* too small, so we must have died very early before we even get a chance to write any configuration on first-start. The "ERROR: Cannot determine language" is then a symptom of that. Just to be sure of where we stand, can I get the output of...

a) rpm -qa|grep libreoffice

and the output of

b) rpm -V `rpm -qa|grep libreoffice|xargs`

and does a prior ~/.openoffice.org dir exist ?

I think what might be helpful is to try and get a strace of a recreation of the original first-start situation which must have failed, e.g. 

rm -rf ~/.libreoffice && strace -f /usr/lib64/libreoffice/program/soffice.bin > /tmp/strace.log 2>&1
Comment 8 Brian Fristensky 2012-06-24 22:39:47 EDT
Created attachment 594086 [details]
output from rpm -qa|grep libreoffice > rpm.out
Comment 9 Brian Fristensky 2012-06-24 22:41:18 EDT
Created attachment 594087 [details]
output from rpm -V `rpm -qa|grep libreoffice|xargs` > rpmV.out
Comment 10 Brian Fristensky 2012-06-24 22:42:41 EDT
Created attachment 594088 [details]
screen messages from rpm -V `rpm -qa|grep libreoffice|xargs` > rpmV.out
Comment 11 Brian Fristensky 2012-06-24 23:18:35 EDT
Created attachment 594095 [details]
strace using original .openoffice.org

I deleted .libreoffice and restored the .openoffice.org directory from a 2 week old backup. Then tried running 

strace -f /usr/lib64/libreoffice/program/soffice.bin > /tmp/strace.log 2>&1

Notably, this time, the splash screen did NOT appear. Only the popup error message as shown in attachment 593922 [details]. And, again libreoffice did not launch.

As previously, a very minimal .libreoffice directory was created.
Comment 12 Caolan McNamara 2012-06-25 04:46:55 EDT
I wonder why it appears to be reopening the .xcd files again and again. Once should be enough.
Comment 13 Caolan McNamara 2012-06-27 12:01:03 EDT
can't figure out a reason for this, and am unable to reproduce. So...

if there is *no* .openoffice.org and there is *no* .libreoffice dir, i.e. rm -rf .openoffice.org .libreoffice and you launch libreoffice it fails in exactly the same way, right ? i.e. I don't think we're looking at a config migration failure.

Is there anything special about how your home dir is mounted ?, and/or is there sufficient free diskspace on /home ?
Comment 14 Brian Fristensky 2012-06-27 12:47:00 EDT
(In reply to comment #13)
> can't figure out a reason for this, and am unable to reproduce. So...
> 
> if there is *no* .openoffice.org and there is *no* .libreoffice dir, i.e. rm
> -rf .openoffice.org .libreoffice and you launch libreoffice it fails in
> exactly the same way, right ? i.e. I don't think we're looking at a config
> migration failure.
> 
> Is there anything special about how your home dir is mounted ?, and/or is
> there sufficient free diskspace on /home ?

Back in September, I posted the following to the OpenOffice.org bugzilla
https://issues.apache.org/ooo/show_bug.cgi?id=118239

3. This bug happens on an account by account basis. That is, it happens to each
user on the system, independently, after one or more uses of OO or LO. An
important point here is that once either program is broken, both are broken.
If I create a NEW user account, the first time I try to use OO or LO, the
program works. After one or more launches, suddenly both no longer work at all.

There is oodles of disk space in /home, so that's not a problem. 

Hey, I wonder if it could be something in /tmp? One of the things that has always nagged me is that an awful lot of the applications in gnome/Fedora/RedHat etc. leave a lot of old files and directories in /tmp. There are all sorts of things going back many months, from various applications. Examples:

4fc817b951376 -> /etc/cups/ppd/Lexmark-C543.ppd
hsperfdata_user
keyring-uP9L8o
lusu2hzd.tmp
pulse-cQdeHA5R9M6F
orbit-user
mozilla-media-cache
svcnp.tmp
virtual-user.R7Kt5A

(I've changed usernames and some characters.) In turn, many of these directories have lots and lots of things in them. The fact that users often can launch LO exactly once, and then have it stop working, would be consistent with something bad being left in /tmp, which LO reads. (That is complicated by the fact that other users don't even get to run LO even once, although all of them have previously run OpenOffice, when it was still on the system.) Still, if it was, say, a conflict of libraries, you would expect it to break for everybody right from the beginning.

The /tmp hypothesis would also be consistent with the observation that many others have made, that they can uninstall LO and reinstall it, and it still doesn't work.

I should point out that I'm running a RHEL6.2 system that was installed fresh, reformatting the hard drive, and dutifully running the updates thereafter. The ONLY non RHEL package that installed was VLC, using rpms from the VLC web site. (That, by the day, doesn't work because of library conflicts.)

So if it was something persisting in /tmp, presumably one could delete everything in /tmp and reboot, and LO should work again. If I did delete the entire contents of /tmp, am I in for any nasty surprises? I am going to guess that the correct procedure would be to logout, shift to a text screen (eg. ctrl-alt-F3), login as root, and then

cd /tmp
rm -rf ./* ./.*  {even contemplating this makes me nervous}
                 {did I get this right so as to include dot files?}
restart

Or, maybe a less potentially destructive way would be to create a new user, try to launch LO, and then do some sort of find in /tmp to see which files were changed at the moment LO started up.
Comment 15 Michael Stahl 2012-06-27 13:26:38 EDT
while i really hope that a LO process doesn't read anything from
/tmp that the same process has written, the easiest way to try
that out is to put /tmp on a tmpfs, that way it will get cleared
automatically on reboot.

e.g. on my Fedora 17 system i have the following in /etc/fstab:
tmpfs   /tmp    tmpfs   nodev,nosuid    0 0
Comment 16 Michael Stahl 2012-06-27 13:27:46 EDT
err i meant "i hope that a LO process doesn't read anything from
/tmp that the same process has _not_ written"
Comment 17 Brian Fristensky 2012-06-27 13:43:17 EDT
My current /etc/fstab has

tmpfs                   /dev/shm                tmpfs   defaults        0 0

which I assume is RHEL's default.

So to make sure I am getting this right, comment out that line and
replace it with 

tmpfs   /tmp    tmpfs   nodev,nosuid    0 0

then reboot. Then retry launching LO.
Comment 18 Brian Fristensky 2012-06-27 13:49:29 EDT
Rereading my above comment, I realize that the line I showed probably has
no relation to /tmp. Here's my complete fstab:

#
# /etc/fstab
# Created by anaconda on Sun Sep 11 08:33:42 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_orpheus-lv_root /                       ext4    defaults        1 1
UUID=xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx /boot                   ext4    defaults        1 2
/dev/mapper/vg_orpheus-lv_home /home                   ext4    defaults        1 2
/dev/mapper/vg_orpheus-lv_swap swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

I masked UUID above, in case it's a potential security hole.
Comment 19 Michael Stahl 2012-06-27 14:45:27 EDT
hi Brian,

/etc/fstab can contain many tmpfs mounts, and i guess you shouln't
remove any existing ones because that will probably break something,
just add a new line for /tmp at the end is enough.
Comment 20 Brian Fristensky 2012-06-27 16:36:45 EDT
(In reply to comment #15)
> while i really hope that a LO process doesn't read anything from
> /tmp that the same process has written, the easiest way to try
> that out is to put /tmp on a tmpfs, that way it will get cleared
> automatically on reboot.
> 
> e.g. on my Fedora 17 system i have the following in /etc/fstab:
> tmpfs   /tmp    tmpfs   nodev,nosuid    0 0

Okay, so I deleted .libreoffice, added the above line to /etc/fstab, and rebooted. I checked /tmp after reboot and indeed, the old files were gone, with just a small number of new files and directories.

The result was the same as before: launch LO, and you get the splashscreen, and then the error popup.

So, I guess we can rule out the hypothesis that nefarious file persists in /tmp.
Comment 21 Stephan Bergmann 2012-07-09 06:50:22 EDT
Brian, can you give the output of "set" from a (bash) shell from which starting soffice would fail?
Comment 22 Brian Fristensky 2012-07-09 22:10:59 EDT
(In reply to comment #21)
> Brian, can you give the output of "set" from a (bash) shell from which
> starting soffice would fail?

Stephan,

I have found a reproducible way to go back and forth between fixing LibreOffice and breaking it. I will attach two files showing the output of set when LO works, and when it doesn't. (set_ooworks.txt and set_oobroken.txt).

Briefly, what happened is that my .bashrc sources another file called profile.source that sets a large number of environment variables, and does a few other things such as turning off noclobber, 'ulimit -c 0', and setting a custom prompt. When I comment out the '.' line that runs profile.source, LibreOffice launches. If I uncomment the '.' line, LO no longer works. I have managed to turn LO on and off many times, so it seems like my profile.source file must be the culprit.

Most of the enviroment variables set in profile.source have obscure names specific for a package of bioinformatics programs that I use, so I doubt there are any environment variable conflicts. Notably, I do NOT set LD_LIBRARY_PATH (I know the trouble that can cause). 

Given enough time I can probably track down the offending lines in profile.source. However, I was wondering if you had anything specific in mind
when you asked about the output from 'set'? That might give me a clue as to what to look for.

As an aside, there seem to have been several people reporting various fixes that eliminate the error message, and they are not necessarily related. I am thinking that there may be a number of ways of causing LO to generate the "general error" message, and to prevent LO from running.
Comment 23 Brian Fristensky 2012-07-09 22:13:45 EDT
Created attachment 597192 [details]
output from set when LO fails to launch
Comment 24 Brian Fristensky 2012-07-09 22:15:12 EDT
Created attachment 597193 [details]
output from set when LO works
Comment 25 Stephan Bergmann 2012-07-10 03:15:40 EDT
This is upstream <https://bugs.freedesktop.org/show_bug.cgi?id=42961> "Setting $DATA causes LibreOffice to crash" first fixed in upstream LibreOffice 3.5.2.

As a workaround, you could make sure to not have environment variables DATA or SCHEMA set.

(Re "I am thinking that there may be a number of ways of causing LO to generate the 'general error' message, and to prevent LO from running."  Yes, this is one of a few messages that appear when something fatal happens internally during early start up.  It can have various reasons and the error message does not always reflect the true problem.  Another common---and often misleading---message is something about failure to determine a UI language.)
Comment 26 RHEL Product and Program Management 2012-07-10 03:56:16 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.