Bug 1294996

When the application habgs the system monitor shows that LibreOffice is waiting on a pipe.

Please start LibreOffice from a terminal shell as

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

(you can terminate it once it hangs with Ctrl-C in the terminal), and attach the resulting log.txt file.

I have run the strace and found something strange. Running soffice.bin from the command line with or without strace actually works. What does not work is clicking on a document in the GUI or starting LibreOffice from the GUI and then attempting to open a new/existing document.

All the workstations only have the Cinnamon desktop installed. They do not have Gnome or KDE installed. It must be some interaction between Cinnamon and LibreOffice that is the problem, which makes sense because when it hags after double clicking on a document and the System Monitor reports it is waiting on a pipe.

Let me know if you need other information.

(In reply to David Ashley from comment #3)
> I have run the strace and found something strange. Running soffice.bin from
> the command line with or without strace actually works. What does not work
> is clicking on a document in the GUI or starting LibreOffice from the GUI
> and then attempting to open a new/existing document.

Ah, right, running directly soffice.bin shortcuts setting the environment variable SAL_ENABLE_FILE_LOCKING=1 in the soffice wrapper script.  Please try

  strace -f -t /usr/lib64/libreoffice/program/soffice >log.txt 2>&1

instead (i.e., without the ".bin"), that should probably expose the problem.

This is definitely a Cinnamon desktop problem. Everything works from the command line. But if I start LibreOffice from an icon, do a File->Open on a remote file, or doubleclick a remote file, then the application hangs.

If I start the application from a command line and then do a File->Open on a remote file the it works. It also works if I start the application from a command line and pass a remote file as a command line parameter.

Very strange.

Created attachment 1112186 [details]
strace of soffice hang when opening nfs4 mounted file

I was finally able to get an strace of the hang and I have attached it. If you need anything else please let me know.

The relevant part being

> [pid 26709] 08:03:21 access("/imports/marvin/dashley/coverletter.odt", F_OK) = 0
> [pid 26709] 08:03:21 lstat("/imports/marvin/dashley/coverletter.odt", {st_mode=S_IFREG|0664, st_size=22189, ...}) = 0
> [pid 26709] 08:03:21 open("/imports/marvin/dashley/coverletter.odt", O_RDWR|O_EXCL) = 33
> [pid 26709] 08:03:21 fstat(33, {st_mode=S_IFREG|0664, st_size=22189, ...}) = 0
> [pid 26709] 08:03:21 fcntl(33, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0} <unfinished ...>

and then never coming back.

David, what exactly did you do to obtain that strace now, given your comment 5?

First, I am still getting hangs somewhat randomly when opening remote files no matter how I start LibreOffice. I was too optimistic in my previous assessment.

For this trace, I ran your strace command. That brings up the main soffice window. From there I did a File->Open on a remote file and that causes the hang. This scenario sometimes works and sometimes not. Mostly it fails. However, it always works on local files. For that matter I can state flatly that it never hangs when opening a local file. Why it fails on NFS4 remote files is a mystery to me.

Let me know if you need anything else.

* "When the application habgs the system monitor shows that LibreOffice is waiting on a pipe."  You mean some /tmp/OSL_PIPE_*_SingleOfficeIPC_*?  That's unrelated and expected:  The first LO instance starts listening on a well-known socket, so that if the user should start further LO instances, they can notify the original instance via that socket and terminate again, instead of running in parallel.


* One temporary workaround you can try is disabling LO's file locking by commenting out the line

  export SAL_ENABLE_FILE_LOCKING

by temporarily changing it to

  # export SAL_ENABLE_FILE_LOCKING

in /usr/lib64/libreoffice/program/soffice (you need to do that with root privileges, of course).  As explained at <http://opengrok.libreoffice.org/xref/core/readlicense_oo/docs/readme.xrm#152>:  "File locking is enabled by default in [LO].  On a network that uses the Network File System protocol (NFS), the locking daemon for NFS clients must be active.  To disable file locking, edit the soffice script and change the line 'export SAL_ENABLE_FILE_LOCKING' to '# export SAL_ENABLE_FILE_LOCKING'.  If you disable file locking, the write access of a document is not restricted to the user who first opens the document."

As discussed in comment 7, a hanging fcntl(F_SETLK F_WRLCK) on an NFS4-mounted file.  Tentatively moving this to kernel, as there appears to be no more specific component that matches.  If necessary, please pass on as appropriate.

This fix works for me. File locking is almost a non issue at my site.

Thanks for all your help. Feel free to close this bug.