Description of problem: Libreoffice locks up and is unable to be stopped or restarted when opening a file from an SMB share. I do not know if the problem occurs with other types of network shares, but I suspect it does. If I copy the file locally and then open it, Libreoffice works fine. Version-Release number of selected component (if applicable): libreoffice-3.6.3.2-8.fc18.x86_64 How reproducible: Try and open a word doc or excel spreadsheet from an SMB share Steps to Reproduce: 1. 2. 3. Actual results: Libreofffice locks up while starting and cannot be restarted until after a reboot Expected results: File opens in Libreoffice Additional info:
+1 from me and someone please flag this as a high priority if not critical. Libreoffice is currently useless for me. Same version as OP. aneil2 4690 1 0 Jan15 ? 00:00:00 /usr/lib64/libreoffice/program/soffice.bin --calc /home/aneil2/Documents/Scoring Grid.xlsx --splash-pipe=7 aneil2 4867 1 0 Jan15 ? 00:00:00 /usr/lib64/libreoffice/program/oosplash --calc /run/user/72599/gvfs/smb-share:server=xxx.xxx.gmu.edu,share=aneil2/shared/Scoring Grid.xlsx aneil2 4881 4867 0 Jan15 ? 00:00:01 /usr/lib64/libreoffice/program/soffice.bin --calc /run/user/72599/gvfs/smb-share:server=xxx.xxx.gmu.edu,share=aneil2/shared/Scoring Grid.xlsx --splash-pipe=7 aneil2 25381 1 0 09:58 ? 00:00:00 /usr/lib64/libreoffice/program/oosplash --impress /home/aneil2/Download/New Graduate Student Orientation PT2-Fall 2012.ppt aneil2 25393 1 0 09:58 ? 00:00:00 /usr/lib64/libreoffice/program/oosplash --impress /home/aneil2/Download/New Graduate Student Orientation PT2-Fall 2012.ppt with strace I see the process try and access this file descriptor and then hangs connect(4, {sa_family=AF_FILE, sun_path="/tmp/OSL_PIPE_72599_SingleOfficeIPC_1e335fd5c08a9e1735b1de20675f196"}, 110) presumably this is to try and contact an existing instance of libreoffice. If I remove this file then I can run the application. I agree with the OP that is seems to be triggered by trying to save a document on a SMB share.
When you start multiple instances of soffice (which calls oosplash, which calls soffice.bin) concurrently, all but the first instance hand off their command line arguments to the first instance (via IPC involving that /tmp/OSL_PIPE_*_SingleOfficeIPC_*), wait for confirmation from the first instance that it processed the arguments, and then terminate again. What happened in comment 1 is that the first instance (soffice.bin 4690) is hung and so any newly started instances (oosplash 25381 and 25393) hang, too. One oddity is that two instances managed to go from oosplash to soffice.bin (4690 and 4881), this smells like the race conditions addressed with <http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0&id=8376da60d5d272cf6b3ebee91934bbcd970c7658> "startup: more reliable startup of multiple instances" and <http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0&id=6527b8a135c20e223a6fcf7c49835205a99ff02a> "Related fdo#33484: Terminate OfficeIPCThread by closing the accepting pipe" for LibreOffice 4.0, but never backported to LibreOffice 3.6. Lets see if backporting them solves the problem.
I installed the released version of Fedora 18 x86_64, same problem with LibreOffice. I will be glad to apply any updates from the testing repository when this is backported and released.
libreoffice-3.6.5.2-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/libreoffice-3.6.5.2-2.fc18
Package libreoffice-3.6.5.2-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreoffice-3.6.5.2-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2042/libreoffice-3.6.5.2-2.fc18 then log in and leave karma (feedback).
I have updated to the following RPMs: libreoffice-graphicfilter-3.6.5.2-2.fc18.x86_64 libreoffice-langpack-en-3.6.5.2-2.fc18.x86_64 libreoffice-math-3.6.5.2-2.fc18.x86_64 libreoffice-writer-3.6.5.2-2.fc18.x86_64 libreoffice-calc-3.6.5.2-2.fc18.x86_64 libreoffice-presenter-screen-3.6.5.2-2.fc18.x86_64 libreoffice-ure-3.6.5.2-2.fc18.x86_64 libreoffice-draw-3.6.5.2-2.fc18.x86_64 libreoffice-core-3.6.5.2-2.fc18.x86_64 libreoffice-xsltfilter-3.6.5.2-2.fc18.x86_64 libreoffice-opensymbol-fonts-3.6.5.2-2.fc18.noarch libreoffice-impress-3.6.5.2-2.fc18.x86_64 libreoffice-pdfimport-3.6.5.2-2.fc18.x86_64 I still experience exactly the same behavior. Here is what appears to be running in LibreOffice: walkerb 1893 0.1 0.3 230784 3304 ? Sl 13:18 0:00 /usr/lib64/libreoffice/program/oosplash --calc /run/user/1000/gvfs/smb-share:server=mlknrmc1,share=rmc1dv04/MIS/SAP Tech/Basis/2008 PE1.XLS walkerb 1907 0.2 5.7 758608 58444 ? Dl 13:18 0:00 /usr/lib64/libreoffice/program/soffice.bin --calc /run/user/1000/gvfs/smb-share:server=mlknrmc1,share=rmc1dv04/MIS/SAP Tech/Basis/2008 PE1.XLS --splash-pipe=6 LibreOffice is as hung as ever.
So your problem must be something other than what is addressed with the fix in comment 2. Once LibreOffice is hung, and <N> is the PID of the hung soffice.bin process, please in a terminal run "gdb - <N>", and then at the gdb prompt "thread apply all backtrace" and attach the output here (and then "kill" and "quit"). Another useful piece of information could be to run "strace -f /usr/bin/soffice '/run/user/1000/gvfs/smb-share:server=mlknrmc1,share=rmc1dv04/MIS/SAP Tech/Basis/2008 PE1.XLS' >log.txt 2>&1" from a terminal and, once LibreOffice hangs, attach the generated log.txt.
Created attachment 696232 [details] strace log
I've attached the log from strace. Unfortunately the gdb command did not seem to work.
The relevant lines from the attached strace log are > [pid 2068] open("/run/user/1000/gvfs/smb-share:server=mlknrmc1,share=rmc1dv04/MIS/SAP Tech/Basis/2008 PE1.XLS", O_RDWR|O_EXCL) = 24 > [pid 2068] fstat(24, {st_mode=S_IFREG|0700, st_size=117248, ...}) = 0 > [pid 2068] fcntl(24, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0 ... > [pid 2068] pread(24, <unfinished ...> that show that the soffice.bin process is blocking on the pread system call, trying to read the file on the SMB share. This might have to do with the advisory locking (the fcntl(F_SETLK) system call) that LibreOffice routinely uses. You can check that by (temporarily) disabling LibreOffice's advisory file locking by unsetting the SAL_ENABLE_FILE_LOCKING environment variable, by commenting out two lines near the head of /usr/lib64/libreoffice/program/soffice like so (adding the "#" characters at the start of the two lines): #SAL_ENABLE_FILE_LOCKING=1 #export SAL_ENABLE_FILE_LOCKING @gdaschner: Is any such problem known with Samba, or is this even more likely related to gvfs (given the mention of "gvfs" in the pathname), or is there anything else we should ask the reporter to help track this down?
Created attachment 696601 [details] strace log again Ran another strace after changing /usr/lib64/libreoffice/program/soffice to values: # file locking now enabled by default #SAL_ENABLE_FILE_LOCKING=1 #export SAL_ENABLE_FILE_LOCKING Unfortunately LibreOffice still hung
libreoffice-3.6.5.2-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #11) > Ran another strace after changing /usr/lib64/libreoffice/program/soffice to > values: > > # file locking now enabled by default > #SAL_ENABLE_FILE_LOCKING=1 > #export SAL_ENABLE_FILE_LOCKING > > Unfortunately LibreOffice still hung ...and the fcntl(24, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) call is indeed gone from the log, so the hung pread appears unrelated to any locking. I'm out of ideas what might cause this, but it might help if you give us the line of "mount" output that shows how exactly that /run/user/1000/gvfs/smb-share:server=mlknrmc1,share=rmc1dv04/MIS/SAP Tech/Basis/2008 PE1.XLS file is mounted, so we can dispatch this issue to the relevant component.
Here is the output of the mount command: [root@localhost walkerb]# mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,size=497508k,nr_inodes=124377,mode=755) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) /dev/mapper/fedora-root on / type ext4 (rw,relatime,data=ordered) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) debugfs on /sys/kernel/debug type debugfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) mqueue on /dev/mqueue type mqueue (rw,relatime) tmpfs on /tmp type tmpfs (rw) configfs on /sys/kernel/config type configfs (rw,relatime) /dev/sda1 on /boot type ext4 (rw,relatime,data=ordered) gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) It doesn't appear that anything for the SMB share shows up. What I do is to use the file manager (nautilus, nemo, caja) to browse to a bookmarked SMB share, enter my credentials for the share, and then try and open the XLS file. Unfortunately I am not very familiar with gvfs and how it works or mounts filesystems. If I copy the file locally and then open it, LibreOffice works fine.
@tbzatek, please take over. (One additional data point as discussed on IRC is that /usr/share/applications/libreoffice-writer.desktop contains X-GIO-NoFuse=true so that soffice should not be passed a/run/user/1000/gvfs/smb-share:server=mlknrmc1,share=rmc1dv04/MIS/SAP Tech/Basis/2008 PE1.XLS pathname.)
Any update or additional testing required from my end?
I've been keeping my Fedora 18 x86_64 system up to date. This issue still occurs, so I was wondering if there is any update on where it stands or what else to try.
I just tried using the rpms for LibreOffice 4.0 from the official download site. These also fail with the same lockup.
Zaphod Beeblebrox: We tracked this down to LibreOffice erroneously being called from the file manager with a "bad" pathname for accessing the file on the SMB share. That is, the issue cannot be solved on the LibreOffice side and is now assigned to the gvfs component. A workaround might be to open the document from within LibreOffice via "File - Open...", maybe after first setting "Tools - Options... - LibreOffice - General - Open/Save dialogs - Use LibreOffice dialogs".
Thanks for that information. I went back to the LibreOffice 3.6.5 rpms from Fedora 18. When I use the file/open in LibreOffice itself after browsing to an SMB bookmark in the file manager, the files open without issue. I did not even have to change the open/save dialog setting. Any idea when the issue with gvfs and the file manager might be resolved?
Hello?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Any update?
The problem is that libreoffice is accessing the smb file via the gvfs fuse filesystem, which is not supported. libreoffice-writer.desktop has: X-GIO-NoFuse=true which means that it should pass the smb:// uri, not the fuse path when the file is opened. I just tested (on F19) that this does still happen for me if i open a file from nautilus. It seems this is broken on your system though, i wonder why.
I can reproduce the problem when I copy /usr/share/applications/libreoffice-writer.desktop to ~/.local/share/applications/libreoffice-writer.desktop and remove the line X-GIO-NoFuse=true from the latter. Zaphod, do you have any such overriding *.desktop files in ~/.local/share/applications/ or /usr/local/share/applications/?
No, I am just using the standard menu and I don't have any desktop shortcuts. I've since moved on to F19 and the problem doesn't seem to exist there. Zaphod
*** Bug 1021572 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.