Description of problem: When trying to double click on a .odp file, openoffice.org starts up but fails before fully activating. Does not even trigger a ABRT incident. Version-Release number of selected component (if applicable): 1. openoffice.org-core-3.3.0-18.2.fc14.x86_64 2. Linux vostro.sin.redhat.com 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux How reproducible: 1. Double click on a .odp file 2. System shows that ooimpress is being started, but nothing happens and ooimpress fails silently. Steps to Reproduce: 1. Double click on a .odp file or from a terminal, run: ooimpress file.odp 2. there will be some activities and then it fails silently Expected results: 1. ooimpress should have started and offered the file for edit. Additional info: 1. while logged in as a normal user, within the desktop, start a terminal. 2 in the terminal, su - to root 3. start ooimpress file.odp 4. ooimpress starts correctly and all is well. 5. this suggested that openoffice.org is OK, just that there is some issue within the user that I was logged in. 6. checking /tmp, I found a file: OSL_PIPE_500_SingleOfficeIPC_9b6fe25a74ede9679728154c992740a1 7. rm'ed the file and then as a normal user, ooimpress file.odp started normally. 8. Looks like for some reason, the residual file in /tmp, OSL* above, which was created two days ago was causing the issue. Removing it solved the problem.
I just ran into the same thing. Running ooffice from the command line did trigger an abrt crash report. May be the cause of bug 667082 and bug 667404.
(In reply to comment #1) > I just ran into the same thing. Running ooffice from the command line did > trigger an abrt crash report. May be the cause of bug 667082 and bug 667404. Did you try to start ooffice as root or another user? Harish
The problem only affected one user - another user could run ooffice just fine. Never ran it as root. Removing the /tmp IPC pipe fixed it for me as well.
(In reply to comment #3) > The problem only affected one user - another user could run ooffice just fine. > Never ran it as root. Removing the /tmp IPC pipe fixed it for me as well. Good to know that the solution seems to be removal of that IPC pipe in /tmp. I am testing out LibreOffice as well and have not seen this issue yet.
I experienced this as well. I've annotated some lines with # comments bash-4.1$ oocalc # nothing happened bash-4.1$ echo $? 0 bash-4.1$ ls /tmp/O* /tmp/OSL_PIPE_4121_SingleOfficeIPC_a7279bf8114e9fba64b64ad0f3c26cd6 bash-4.1$ ls -l /tmp/OSL* srwxrwxr-x. 1 sps sps 0 Jan 6 23:24 /tmp/OSL_PIPE_4121_SingleOfficeIPC_a7279bf8114e9fba64b64ad0f3c26cd6 bash-4.1$ oowriter # nothing happened bash-4.1$ echo $? 0 bash-4.1$ ps auxwww | grep oowriter sps 26551 0.0 0.0 103416 840 pts/3 S+ 15:11 0:00 grep oowriter bash-4.1$ rm /tmp/OSL* bash-4.1$ oowriter # oowriter starts just fine bash-4.1$ ls -l /tmp/OSL* ls: cannot access /tmp/OSL*: No such file or directory # ...and cleans up after exiting normally I suspect that some forms of openoffice exit (e.g., sudden power loss) leave behind the pipe file. Possible workaround: on openoffice component startup, check that there is a process listening to the pipe (with, e.g., lsof) and remove it if not.
> I suspect that some forms of openoffice exit (e.g., sudden power loss) leave > behind the pipe file. That's right, but it's not a problem. > Possible workaround: on openoffice component startup, > check that there is a process listening to the pipe (with, e.g., lsof) and > remove it if not. But that's not what you did. Otherwise you would probably have found that there indeed was a process listening on the socket... (In reply to comment #5) > I experienced this as well. I've annotated some lines with # comments > > bash-4.1$ oocalc > # nothing happened > bash-4.1$ echo $? > 0 > bash-4.1$ ls /tmp/O* > /tmp/OSL_PIPE_4121_SingleOfficeIPC_a7279bf8114e9fba64b64ad0f3c26cd6 > bash-4.1$ ls -l /tmp/OSL* > srwxrwxr-x. 1 sps sps 0 Jan 6 23:24 > /tmp/OSL_PIPE_4121_SingleOfficeIPC_a7279bf8114e9fba64b64ad0f3c26cd6 > bash-4.1$ oowriter > # nothing happened > bash-4.1$ echo $? > 0 > bash-4.1$ ps auxwww | grep oowriter > sps 26551 0.0 0.0 103416 840 pts/3 S+ 15:11 0:00 grep oowriter That would be pretty conclusive if the actual binary were named oowriter. Unfortunately, it's not. What's the output of either lsof /tmp/OSL_PIPE_4121_SingleOfficeIPC_a7279bf8114e9fba64b64ad0f3c26cd6 or ps -C swriter.bin ?
Remembering that things are now working correctly, this is what I get: bash-4.1$ lsof /tmp/OSL_PIPE_4121_SingleOfficeIPC_a7279bf8114e9fba64b64ad0f3c26cd6 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME soffice.b 3148 sps 8u unix 0xffff88009254c000 0t0 22889 /tmp/OSL_PIPE_4121_SingleOfficeIPC_a7279bf8114e9fba64b64ad0f3c26cd6
In our case, I wonder if having multiple sessions (desktop + vncserver) on a single machine is causing this. Can OOo handle this?
If the same user is logged in multiple times then that would explain this i.e. another OOo belonging to that user running on a different display. Otherwise I can't reproduce this problem. rm the pipe just cuts the connection so that two instances can be run, instead of the usual one, with all the consequent possible problems of munging the personal config dir as I bet there's no support to make that safe. Assuming I'm right, then this is "just the way it work" unfortunately. If I'm wrong, i.e. someone has a reproducible scenario feel free to fill in those details and reopen this.