Bug 151913 - Libreoffice won't start if home directory is mounted on mergerFS
Summary: Libreoffice won't start if home directory is mounted on mergerFS
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.4.7.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-04 22:06 UTC by jczarniak
Modified: 2022-11-05 14:47 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
LO strace (29.30 KB, text/plain)
2022-11-04 22:06 UTC, jczarniak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jczarniak 2022-11-04 22:06:19 UTC
Created attachment 183423 [details]
LO strace

I'm unable to start any LO components if /home directory (most likely some relevant to LO parts of it) is located on mergerFS.

yaro@yaro-desktop2:~$ mergerfs.ctl info
- mount: /home
  version: 2.33.5
  pid: 630
  srcmounts:
    - /mnt/md0
    - /mnt/md1
yaro@yaro-desktop2:~$ 

yaro@yaro-desktop2:~$ findmnt /home
TARGET SOURCE   FSTYPE        OPTIONS
/home  mergerfs fuse.mergerfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other
yaro@yaro-desktop2:~$ 

------------

LO execution example (no output, nor error at all):
yaro@yaro-desktop2:~$ C_ALL=C libreoffice --version
yaro@yaro-desktop2:~$ 

And now if I "redirect" $HOME to the drive where .config (and most of the other /home content) is located:
yaro@yaro-desktop2:~$ LC_ALL=C HOME="/mnt/md1/yaro" libreoffice --version
LibreOffice 6.4.7.2 40(Build:2)

yaro@yaro-desktop2:~$ 

It works fine. Writer, calc etc can be started without any problems. For some reasons, LO doesn't like mergerFS and just exit without any message or error. 

I also checked strace but it did not provide me any extra information. But I'm not good at it. :) Output provided in attachment.

I observe the same behavior on ubuntu 22.04, neon 20.04 and some relatively new fedora. So it's not distro related.


I also reported bug on mergerFS github at: https://github.com/trapexit/mergerfs/issues/1086
Comment 1 Eike Rathke 2022-11-05 11:44:09 UTC
May be related to mmap() calls that seems to conflict with your mergeFS cache.files=off setting you mentioned there. Use cache.files=partial,dropcacheonclose=true instead, see https://github.com/trapexit/mergerfs#you-need-mmap-used-by-rtorrent-and-many-sqlite3-base-software

Unfortunately your strace at https://gist.github.com/SirYaro/4f80d2e880fb72cb31fabc9bdb76bf50 was executed without the -f or --follow-forks option so what's actually happening can't be seen.
Comment 2 jczarniak 2022-11-05 12:32:04 UTC
Please find new strace output in here:
https://gist.github.com/SirYaro/91032fba97c3d9aadd6fbcf28f4709c1

(LC_ALL=C strace -f -o /tmp/LO-strace2.txt libreoffice --version)
Comment 3 jczarniak 2022-11-05 14:29:18 UTC
Hi Eike

Enabling cache helped indeed. But bth I'm not the biggest fan of this feature, and I'm wondering if it is possible to do something on Libreoffice side....
Comment 4 jczarniak 2022-11-05 14:47:55 UTC
msg from mergerfs developer:


trapexit 

Then it is probably that they are using mmap and they aren't using fallbacks. If so there is nothing I can do.