https://bugs.documentfoundation.org/show_bug.cgi?id=172722
Bug ID: 172722
Summary: soffice.bin intermittently fails to open a document
window when invoked via desktop file activation
(Nautilus/Thunar double-click or dock/launcher "Start
Center"), while the process starts, briefly creates
its IPC pipe, and then exits silently without any
Product: LibreOffice
Version: 26.2.4.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
Description:
Component: LibreOffice
Version: 26.2.4.2 (Ubuntu package 4:26.2.4.2-0ubuntu0.26.04.1)
OS: Linux (Ubuntu 26.04 LTS, GNOME 50, Wayland session — no X11/Xorg session
available on this release)
Steps to Reproduce:
Double-click a .docx file in a file manager (e.g. Thunar) — Writer opens
correctly.
Close the document window.
Double-click a second .docx file — Writer opens correctly.
While this document is still open, click the LibreOffice Start Center icon in
the dock/launcher.
→ No new window appears. No error is shown.
Close the open document.
Click the Start Center icon again.
→ This time it opens correctly.
Close the Start Center.
Double-click a .docx file again.
→ No window appears. No error is shown.
Actual Results:
Observed Behaviour
ps aux | grep soffice.bin shows no running soffice.bin process after a failed
attempt.
/tmp/OSL_PIPE_<uid>_SingleOfficeIPC_* is freshly recreated at the time of the
failed attempt (confirmed via timestamp), indicating the process did start and
began IPC setup.
No crash, no core dump (coredumpctl list empty), no relevant journalctl entries
for soffice/mutter/wayland at the time of failure.
The process appears to exit cleanly and silently rather than crashing.
A subsequent identical invocation from a terminal (libreoffice
"file:///path/to/file.docx") reliably succeeds every time, even immediately
after a failed desktop-activation attempt.
Forcing GDK_BACKEND=x11 did not reliably prevent the issue.
Issue persists after a full reboot for some time, then recurs (observed again
after a suspend/resume cycle).
No coredump or crash flag is set (Crashed=false in registrymodifications.xcu
RecoveryList entries observed after hard-kill testing, but not relevant to the
silent-exit case above).
Expected Results:
Expected Behaviour
soffice.bin should either reliably create a new document/Start Center window on
every desktop-file-activated invocation, or, if it determines it cannot proceed
(e.g. due to IPC handshake timing with a lingering prior instance), it should
retry internally or report a diagnosable error rather than exiting silently.
Reproducible: Always
User Profile Reset: No
Additional Info:
Environment Notes
Ubuntu 26.04 LTS ships GNOME 50 with no native X11/Xorg session; only Wayland
is available (GNOME upstream removed X11 session code). XWayland remains
available as a compatibility layer for individual applications.
Desktop file used: /usr/share/applications/libreoffice-writer.desktop
(Exec=libreoffice %U), unmodified aside from local troubleshooting (see below).
GIO mime handler registration confirmed correct (gio mime
application/vnd.openxmlformats-officedocument.wordprocessingml.document →
libreoffice-writer.desktop, recommended and default).
Troubleshooting already performed (ruled out as root cause)
Verified no leftover Snap installation of LibreOffice; package is pure .deb
(libreoffice-writer 26.2.4.2-0ubuntu0.26.04.1).
Verified DISPLAY and XAUTHORITY are identical between terminal shell and
file-manager (Thunar) process environment.
Compared full environment dumps (via wrapper script logging) between a
successful terminal invocation and a failed desktop-file invocation — no
meaningful differences found (aside from expected GIO/systemd activation
metadata: DESKTOP_STARTUP_ID, XDG_ACTIVATION_TOKEN, INVOCATION_ID,
GIO_LAUNCHED_DESKTOP_FILE).
A workaround script that clears stale /tmp/OSL_PIPE_* sockets and stale
RecoveryList entries in registrymodifications.xcu before each launch reduces
frequency but does not eliminate the issue.
Increasing wait/retry timeouts in the workaround script (up to 25s) did not
reliably resolve failures, and is impractical as a permanent workaround.
Full desktop-session switch to X11 (attempted previously, including XFCE)
reportedly did not resolve a related issue in the past (per user's prior
experience with other applications), though this specific bug was not tested
that way.
Happy to provide further logs, strace output, or test builds if useful for
diagnosis. This is reproducible on demand following the steps above.
--
You are receiving this mail because:
You are the assignee for the bug.
