U.a. Libreoffice: Startprobleme seit(?) Kernel 5.0.1

Es ist unklar, ob die im Folgenden beschriebenen Symptome auf das neue System oder einen Update in den Tagen zuvor zurückgehen, evtl. im Zusammenhang mit einem Systemcrash.
Die in Frage stehenden Programme hatte ich in der letzten Woche nicht verwendet.
Leider mußte ich wg. drohenden Speichermangels bei einem größeren Update Snapshots, Logs und Caches auf ein Minimum reduzieren.

Symptome:
Start von Libreoffice: Startversuch erfolglos, keine Fehlermeldung - auch nicht bei Start von Konsole.
Yast: nach einem Start über Superuserkonsole jetzt dauerhaft wieder erfolgreicher Start
Start von Libreoffice über Superuserkonsole:

> which libreoffice
/usr/bin/libreoffice
> echo $PATHlibre
/home/heinz/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
> libreoffice heizen4.ods
> ll heizen4.ods
-rw------- 1 heinz users 740842 27. Feb 13:15 heizen4.ods
> ll /usr/bin/libre*
lrwxrwxrwx 1 root root   36 14. Mär 22:07 /usr/bin/libreoffice -> ../lib64/libreoffice/program/soffice
-rwxr-xr-x 1 root root 3132 30. Jan 01:34 /usr/bin/libreoffice-share-linker
su root
Passwort: 
# libreoffice heizen4.ods
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:39.781: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:39.781: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:39.781: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:39.805: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:39.805: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:39.805: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
...
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:53.954: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
** (soffice:9972): CRITICAL **: 23:52:55.981: void g_lo_menu_insert_section(GLOMenu*, gint, const gchar*, GMenuModel*): assertion 'G_IS_LO_MENU (menu)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:55.982: gtk_menu_bar_new_from_model: assertion 'G_IS_MENU_MODEL (model)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:55.982: gtk_widget_insert_action_group: assertion 'GTK_IS_WIDGET (widget)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:55.982: gtk_widget_set_hexpand: assertion 'GTK_IS_WIDGET (widget)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:55.982: gtk_container_add: assertion 'GTK_IS_WIDGET (widget)' failed
(soffice:9972): GLib-GObject-WARNING **: 23:52:55.982: invalid (NULL) pointer instance
(soffice:9972): GLib-GObject-CRITICAL **: 23:52:55.982: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(soffice:9972): GLib-GObject-WARNING **: 23:52:55.982: invalid (NULL) pointer instance
(soffice:9972): GLib-GObject-CRITICAL **: 23:52:55.982: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:55.982: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.004: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.004: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.004: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.005: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.005: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.005: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
...
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.029: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.038: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
...
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.045: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:52:56.045: g_dbus_connection_get_unique_name: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
** (soffice:9972): CRITICAL **: 23:52:56.117: void g_lo_menu_insert_section(GLOMenu*, gint, const gchar*, GMenuModel*): assertion 'G_IS_LO_MENU (menu)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:56.118: gtk_menu_bar_new_from_model: assertion 'G_IS_MENU_MODEL (model)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:56.118: gtk_widget_insert_action_group: assertion 'GTK_IS_WIDGET (widget)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:56.118: gtk_widget_set_hexpand: assertion 'GTK_IS_WIDGET (widget)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:56.118: gtk_container_add: assertion 'GTK_IS_WIDGET (widget)' failed
(soffice:9972): GLib-GObject-WARNING **: 23:52:56.118: invalid (NULL) pointer instance
(soffice:9972): GLib-GObject-CRITICAL **: 23:52:56.118: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(soffice:9972): GLib-GObject-WARNING **: 23:52:56.118: invalid (NULL) pointer instance
(soffice:9972): GLib-GObject-CRITICAL **: 23:52:56.118: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(soffice:9972): Gtk-CRITICAL **: 23:52:56.118: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed
(soffice:9972): GLib-GIO-CRITICAL **: 23:53:05.081: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
...

Sieht nach Problem mit Glib aus - was kann ich tun?

Mit freundlichen Grüßen

Sieht nach Problem mit Glib aus - was kann ich tun?

libre-office nicht als root starten?

Das ist ja genau das Problem - das gibt nichts. Also genau das:

> libreoffice
> libreoffice heizen1.ods
> 

Noch ein im Prinzip völlig anderes Symptom habe ich gesehen, vielleicht hilft das weiter -
Der Versuch, eine Druckvorschau zu erhalten, ergibt:

Druckvorschaukomponente kann nicht geladen werden

Ich habe in /usr/bin/soffice die folgende Anweisung unkommentiert:

# uncomment line below if you encounter problems starting soffice on your system
SAL_NO_XINITTHREADS=true; export SAL_NO_XINITTHREADS

Das ergab, daß oosplash fehlt - warum auch immer:

soffice heizen1.ods
/usr/bin/soffice: Zeile 180: /usr/bin/oosplash: Datei oder Verzeichnis nicht gefunden

Was ist zu tun? Zu welchem Paket gehört oosplash?

Du kannst ja nachschauen, was alles an einem Tag installiert wurde:


grep '2019-03-20' /var/log/zypp/history

zeigt alles am 20.03.2019 installiertes an.

Dann auch noch:

zypper se -si libreoffice

Keine Vorstellung warum - Libreoffice ließ sich soeben erfolgreich starten.
Was genau dazu geführt hat, daß dies zum erstenmal seit Tagen geht, weiß ich nicht, ich habe viel versucht.

Es dürfte so sein, daß i.w. oder “nur” ein alter .ods-Lock-File mit dem vorhergehenden Versagen zu tun hat - sonst wäre dies zusammen damit nur schwer zu erklären, daß sich libreoffice unter root zwar mit vielen Warnungen, aber doch starten ließ, als Normaluser nicht, und ohne Systemänderung diesmal wieder.

Was ich bisher noch nicht erwähnt hatte - das einzige Lebenszeichen von Libreoffice seit Aufspielen des letzten System-Updates war die bei jedem(!) Shutdown wiederkehrende Anfrage, ob die zu den Lock-File zugehörigen Datei wiederhergestellt werden solle - bei “ja” gab’s normalerweise sofort Shutdown, bei “Abbrechen” keinen Shutdown, oder einen nach längerer Zeit, doch beim letzten Shutdown wurde anschließend anscheinend etwas ausgeführt. Schon einmal hatte ich den Lock-File umbenannt, das bewirkte nichts.

Als Erinnerung fiel mir soeben ein strace.log von gestern mittag auf - sollten Sie sich dafür interessieren: wie kann ich ihn schicken ( 45.2 KB )?

Pardon - Ihre Antwort habe ich erst jetzt gesehen. Ist der strace.log - siehe mein voriger Eintrag - interessant?

# grep '2019-03-20' /var/log/zypp/history
# grep '2019-03-19' /var/log/zypp/history
2019-03-19  23:14:20|command|root@linux-u4te|'/usr/bin/ruby.ruby2.6'  '--encoding=utf-8' '/usr/lib/YaST2/bin/y2start' 'sw_single' 'qt' '-name'  'YaST2' '-icon' 'yast'|
2019-03-19  23:15:22|command|root@linux-u4te|'/usr/bin/ruby.ruby2.6'  '--encoding=utf-8' '/usr/lib/YaST2/bin/y2start' 'sw_single' 'qt' '-name'  'YaST2' '-icon' 'yast'|
# zypper se -si libreoffice
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                              | Typ   | Version     | Arch   | Repository            
---+-----------------------------------+-------+-------------+--------+-----------------------
i+ | libreoffice                       | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-base                  | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i  | libreoffice-base-drivers-firebird | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-branding-upstream     | Paket | 6.2.2.1-1.1 | noarch | Haupt-Repository (OSS)
i+ | libreoffice-calc                  | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-calc-extensions       | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-draw                  | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-filters-optional      | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-gnome                 | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-gtk3                  | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-icon-themes           | Paket | 6.2.2.1-1.1 | noarch | Haupt-Repository (OSS)
i+ | libreoffice-impress               | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-l10n-de               | Paket | 6.2.2.1-1.1 | noarch | Haupt-Repository (OSS)
i+ | libreoffice-l10n-en               | Paket | 6.2.2.1-1.1 | noarch | Haupt-Repository (OSS)
i+ | libreoffice-mailmerge             | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-math                  | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-pyuno                 | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-qt5                   | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-share-linker          | Paket | 1-4.5       | noarch | Haupt-Repository (OSS)
i+ | libreoffice-writer                | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | libreoffice-writer-extensions     | Paket | 6.2.2.1-1.1 | x86_64 | Haupt-Repository (OSS)

Die Entwarnung war voreilig.
Zur Sicherheit habe ich nochmal einen Neustart gemacht - jetzt läßt sich wieder nichts vom ganzen Libreoffice-Paket starten.

Sobald nach Systemstart ein Libreoffice-Lockfile eines Users existiert, läßt sich auf meinem jetzigen System Libreoffice für diesen User nicht starten (zumindest in diesem Directory).
Umbenennen des Lockfiles ändert nichts daran.
Ist irgendetwas an meinem System faul oder ist das in dieser Version immer so?

Libreoffice läßt sich danach von diesem User am leichtesten erfolgreich wieder starten nach:

  • Start der Bearbeitung des gesperrten Files unter root
  • Abspeichern des geänderten Files (damit Löschen des Lockfiles)
  • Beenden von Libreoffice
  • Restart

Als root:

zypper dup

https://ask.libreoffice.org/en/question/135501/how-do-i-prevent-these-lock-files-from-being-createddeleted/

Situation deutlich verbessert, Fehler sah nach dem Update gestern als behoben aus, tritt heute nach weiterem Neustart soeben zum erstenmalv wieder auf. Derzeit endet wieder jeder Startversuch von Libreoffice mit Mißerfolg.

Keine Sperrdateien zu sehen, bisherige Vorgehensweise hilft nach Update auf linux-u4te 5.0.2-1-default #1 SMP Thu Mar 14 08:29:17 UTC 2019 (d1f1d19) x86_64 x86_64 x86_64 GNU/Linux
nicht mehr weiter. Libreoffice (soffice) beendet wieder kommentarlos jeden Startversuch.

> sudo zypper dup
[sudo] Passwort für root: 
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Warnung: Sie sind im Begriff, eine Distributionsaktualisierung mit allen aktivierten Repositorys durchzuführen. Vergewissern Sie sich, dass diese Repositorys kompatibel sind, bevor Sie fortfahren. Weitere Informationen zu diesem Kommando finden Sie unter 'man zypper'.
Distributions-Aktualisierungen werden verarbeitet...

Keine auszuführenden Aktionen.

Poste mal:

zypper lr -d
linux-u4te:~ # yzpper dup
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...

Nothing to do.
linux-u4te:~ # zypper dup
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...

Nothing to do.
linux-u4te:~ # 

Welchen Unterschied macht die Ausführung als User root - mit Ausnahme dessen, daß bei root defaultmäßig US-Tastatur eingestellt ist und - was ich nicht wußte - der Bequemlichkeit halber auch “yzpper” definiert ist?

# zypper lr -d
# | Alias                               | Name                            | Aktiviert | GPG-Überprüfung | Aktualisierung | Priorität | Typ    | URI                                                                     | Dienst
--+-------------------------------------+---------------------------------+-----------+-----------------+----------------+-----------+--------+-------------------------------------------------------------------------+-------
1 | download.opensuse.org-non-oss       | Haupt-Repository (NON-OSS)      | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/                   |       
2 | download.opensuse.org-oss           | Haupt-Repository (OSS)          | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/                       |       
3 | download.opensuse.org-tumbleweed    | Hauptaktualisierungs-Repository | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | http://download.opensuse.org/update/tumbleweed/                         |       
4 | http-download.opensuse.org-79378034 | graphics                        | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | http://download.opensuse.org/repositories/graphics/openSUSE_Factory/    |       
5 | http-ftp.uni-erlangen.de-0ebe1fc2   | Packman Repository              | Ja        | (r ) Ja         | Ja             |   96      | rpm-md | http://ftp.uni-erlangen.de/pub/mirrors/packman/suse/openSUSE_Tumbleweed |       
6 | openSUSE-20171213-0                 | openSUSE-20171213-0             | Ja        | (r ) Ja         | Nein           |   99      | yast2  | cd:/?devices=/dev/disk/by-id/ata-HL-DT-ST_DVDRAM_GH24NSD1_K17H14E1519   |       
7 | repo-debug                          | openSUSE-Tumbleweed-Debug       | Nein      | ----            | ----           |   99      | rpm-md | http://download.opensuse.org/debug/tumbleweed/repo/oss/                 |       
8 | repo-source                         | openSUSE-Tumbleweed-Source      | Nein      | ----            | ----           |   99      | rpm-md | http://download.opensuse.org/source/tumbleweed/repo/oss/              

Zugriffsrechte für neu von Libreoffice erzeugte Dateien:
Bis vor wenigen Tagen: -rw-r–r–
Jetzt: -rw-------
Hat das inzwischen wieder vorhandene oosplash etwa damit Probleme?

Es sieht für mich so aus: unvollständiger Update (aber mit neuem Kernel etc.), der nächste Update bessert das aus, aber ohne Nachholen von Dateieinstellungen wie die von LibreOffice.
Es ist also eher wahrscheinlich, daß andere ähnliche Probleme noch folgen werden.

Inzwischen habe ich als Notmaßnahme das Setzen von .lock-Files durch LibreOffice ausgeschaltet.