Bug 885156 - Libreoffice locks up when opening Microsoft Office file over SMB share
Libreoffice locks up when opening Microsoft Office file over SMB share
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gvfs (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Ondrej Holy
Fedora Extras Quality Assurance
: Reopened
: 1021572 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-07 10:52 EST by Zaphod Beeblebrox
Modified: 2014-02-05 17:54 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 17:54:47 EST
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)
strace log (62.74 KB, application/x-gzip)
2013-02-11 12:45 EST, Zaphod Beeblebrox
no flags Details
strace log again (62.31 KB, application/x-gzip)
2013-02-12 15:03 EST, Zaphod Beeblebrox
no flags Details

  None (edit)
Description Zaphod Beeblebrox 2012-12-07 10:52:52 EST
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:
Comment 1 Alastair Neil 2013-01-16 10:20:20 EST
+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.
Comment 2 Stephan Bergmann 2013-01-16 12:10:53 EST
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.
Comment 3 Zaphod Beeblebrox 2013-01-22 17:39:49 EST
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.
Comment 4 Fedora Update System 2013-02-06 04:23:15 EST
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
Comment 5 Fedora Update System 2013-02-07 21:12:17 EST
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).
Comment 6 Zaphod Beeblebrox 2013-02-08 13:24:32 EST
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.
Comment 7 Stephan Bergmann 2013-02-11 08:27:08 EST
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.
Comment 8 Zaphod Beeblebrox 2013-02-11 12:45:36 EST
Created attachment 696232 [details]
strace log
Comment 9 Zaphod Beeblebrox 2013-02-11 12:46:33 EST
I've attached the log from strace. Unfortunately the gdb command did not seem to work.
Comment 10 Stephan Bergmann 2013-02-12 11:23:53 EST
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?
Comment 11 Zaphod Beeblebrox 2013-02-12 15:03:45 EST
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
Comment 12 Fedora Update System 2013-02-12 23:28:45 EST
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.
Comment 13 Stephan Bergmann 2013-02-13 02:39:38 EST
(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.
Comment 14 Zaphod Beeblebrox 2013-02-13 11:18:00 EST
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.
Comment 15 Stephan Bergmann 2013-02-14 09:44:41 EST
@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.)
Comment 16 Zaphod Beeblebrox 2013-02-19 08:50:27 EST
Any update or additional testing required from my end?
Comment 17 Zaphod Beeblebrox 2013-02-26 14:15:35 EST
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.
Comment 18 Zaphod Beeblebrox 2013-02-26 16:24:34 EST
I just tried using the rpms for LibreOffice 4.0 from the official download site. These also fail with the same lockup.
Comment 19 Stephan Bergmann 2013-02-27 03:01:52 EST
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".
Comment 20 Zaphod Beeblebrox 2013-02-27 10:18:52 EST
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?
Comment 21 Zaphod Beeblebrox 2013-04-03 16:25:11 EDT
Hello?
Comment 22 Fedora Admin XMLRPC Client 2013-05-23 10:37:56 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 23 Fedora Admin XMLRPC Client 2013-05-23 10:40:23 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 24 Fedora Admin XMLRPC Client 2013-05-23 10:43:27 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 25 Fedora Admin XMLRPC Client 2013-05-23 10:46:09 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 26 Zaphod Beeblebrox 2013-05-24 13:58:58 EDT
Any update?
Comment 27 Alexander Larsson 2013-08-21 09:12:35 EDT
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.
Comment 28 Stephan Bergmann 2013-08-21 11:14:23 EDT
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/?
Comment 29 Zaphod Beeblebrox 2013-08-26 13:30:21 EDT
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
Comment 30 Stephan Bergmann 2013-10-21 11:52:33 EDT
*** Bug 1021572 has been marked as a duplicate of this bug. ***
Comment 31 Fedora End Of Life 2013-12-21 10:14:30 EST
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.
Comment 32 Fedora End Of Life 2014-02-05 17:54:47 EST
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.

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