Opensuse Leap 42.1 und 13.2 – aktuelle Versionen des freshplayerplugin-Pakets führen zum Crash von Eclipse mit GTK2

Es gibt Probleme, deren Ursachen sind schwer zu finden und können einen in den Wahnsinn treiben. So zuletzt das Phänomen, dass Eclipse mit GTK2 nach Updates sowohl von Opensuse 13.2 als auch Opensuse Leap 42.1 permanent und zunächst scheinbar erratisch abstürzten.

Interessanterweise tauchen die Probleme mit Eclipse unter GTK3 nicht auf. Allerdings zeigt die Eclipse UI unter GTK3 noch einige unschöne Grafik-Probleme.

Es dauerte eine Weile, bis ich herausfand, dass die Abstürze von Eclipse/GTK2 nur auftraten, wenn ich Content Assist Funktionalitäten benutzte (was ich natürlich sehr regelmäßig tue) und dabei Zusatzinformationen zu Elementen der Vorschlagsliste angezeigt wurden. Typischerweise ist es so, dass diese Zusatzinformationen aus HTML-Vorgaben gerendert werden. Die Java Runtime JVM nutzt hierzu “webkit”-Funktionalitäten (der Umgebung).

Es dauerte noch einige Zeit mehr, bis ich herausfand, dass das Problem auf einer frischen Installation von OS 13.2 oder LEAP 42.1 nicht auftrat – wohl aber nach einer Reihe von Updates der Opensuse-Umgebung. Leider ist es durchaus schwierig, herauszufinden, welches Paket unter hunderten genau der Verursacher der Probleme ist. Dass es mit Web/HTML-Rendering zu tun haben musste, war aber klar.

Durch eine Backtrace-Analyse des JVM-Absturzes kam ich heute einen substanziellen Schritt weiter:

Die erhaltenen Absturz-Informationen der JVM zeigten, dass im Rendervorgang auch eine “freshwrapper”-Bibliothek tangiert wurde – genauer:
“/usr/lib64/browser-plugins/libfreshwrapper-pepperflash.so” aus dem Paket freshplayerplugin.

Das Paket “freshplayerplugin” liefert einen nützlichen Firefox-Wrapper für Chromes/Chromiums “pepper-flash”-Plugin. Letzteres ermöglicht das Abspielen von Flash-Inhalten auch unter Firefox – das ist u.a. nützlich für Live-Streams des einen oder anderen Fernsehsenders, der bislang noch nicht auf vernünftige Formate umgestellt hat.

Ich hatte das Paket “freshplayerplugin” unter Leap 42.1 und OS 13.2 im Zuge von Updates in der aktuellsten Variante “0.3.4-20.1” vom Packman-Repository installiert.

Tatsächlich zeigte sich, dass mit einer Installation der Paketversion “0.3.2” aus den jeweiligen Hauptrepositories von SuSE die Eclipse-Absturz-Probleme unter Opensuse Leap 42.1 verschwanden. Bzgl. OS 13.2 muss ich mich noch kundig machen.

Ich hoffe, diese Info zumindest zu Leap 42.1 hilft auch anderen Betroffenen, die Eclipse mit GTK2 nutzen wollen.

systemd Logging Protokolle – journalctl – Abfrage nach Services und Kommandos mit Autocompletion-Hilfe für Vergessliche

Als alter “syslog-ng” Nutzer tue ich mir immer wieder hart mit der Protokollierung durch “systemd”. Der Schlüssel-Befehl “journactl” ist mir natürlich präsent – aber welche Opionen muss ich dann wählen, um die Unzahl von Journal-Einträge nach solchen zu ganz bestimmten Services oder Kommandos zu filtern?

Den entscheidenden Tip für Dummies wie mich habe ich hier gefunden:
http://blog.delouw.ch/2013/07/24/why-journalctl-is-cool-and-syslog-will-survive-for-another-decade/
(Vielen Dank für den hilfreichen Blog-Artikel).

journactl hat eine Autocompletion-Funktionalität über die Tab-Taste:

Generelle Filter-Optionen erreicht man über

journalctl <TAB>[<TAB>]

Ggf. muss man die TAB-Taste 2-mal drücken.

mytux:~ # journalctl 
CODE_FILE=                   _KERNEL_DEVICE=
CODE_FUNC=                   _KERNEL_SUBSYSTEM=
CODE_LINE=                   _MACHINE_ID=
COREDUMP_EXE=                _PID=
ERRNO=                       _SELINUX_CONTEXT=
MESSAGE=                     _SOURCE_REALTIME_TIMESTAMP=
MESSAGE_ID=                  _SYSTEMD_CGROUP=
PRIORITY=                    _SYSTEMD_OWNER_UID=
SYSLOG_FACILITY=             _SYSTEMD_SESSION=
SYSLOG_IDENTIFIER=           _SYSTEMD_UNIT=
SYSLOG_PID=                  _TRANSPORT=
_AUDIT_LOGINUID=             _UDEV_DEVLINK=
_AUDIT_SESSION=              _UDEV_DEVNODE=
_BOOT_ID=                    _UDEV_SYSNAME=
_CMDLINE=                    _UID=
_COMM=                       __CURSOR=
_EXE=                        __MONOTONIC_TIMESTAMP=
_GID=                        __REALTIME_TIMESTAMP=
_HOSTNAME=                   

 
Das ist doch schon sehr hilfreich. Da die meisten System-Services direkt zu irgendwelchen “systemd UNITs” korrespondieren, kommt man hier schon ein gutes Stück weiter. Beispiel:

mytux:~ # journalctl _SYSTEMD_UNIT=sshd.service 
-- Logs begin at Fri 2014-12-19 17:40:02 CET, end at Sun 2015-09-27 19:02:35 CEST. --
......
-- Reboot --
Jan 24 10:49:37 mytux sshd-gen-keys-start[5942]: Checking for missing server keys in /etc/ssh
Jan 24 10:49:37 mytux sshd[5947]: Server listening on 0.0.0.0 port 22.
Jan 24 10:49:37 mytux sshd[5947]: Server listening on :: port 22.
Jan 24 10:50:03 mytux sshd[5971]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33032 ssh2
Jan 24 10:50:03 mytux sshd[5971]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 24 10:50:03 mytux sshd[6013]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33033 ssh2
Jan 24 10:50:03 mytux sshd[6013]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 24 12:10:20 mytux sshd[13201]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33310 ssh2
.......

 
Oder:

mytux:~ # journalctl _SYSTEMD_UNIT=vmware.service 
-- Logs begin at Fri 2014-12-19 17:40:02 CET, end at Sun 2015-09-27 19:07:41 CEST. --
Jan 03 09:31:07 mytux vmware[1475]: Starting VMware services:
Jan 03 09:31:07 mytux vmware[1475]: [33B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [49B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [50B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [30B blob data]
Jan 03 09:31:07 mytux vmnetBridge[1775]: Bridge process created.
Jan 03 09:31:07 mytux vmnetBridge[1775]: RTM_NEWLINK: name:enp8s0 index:2 flags:0x00011043
Jan 03 09:31:07 mytux vmnetBridge[1775]: Adding 
interface enp8s0 index:2
Jan 03 09:31:07 mytux vmnetBridge[1775]: Started bridge enp8s0 to virtual network 0.
.......

 
Erinnert man sich nicht mehr an laufende Services bzw. systemd-Units, so benutzt man die TAB-Taste erneut:

mytux:~ # journalctl  _SYSTEMD_UNIT=<TAB>[<TAB>]
Display all 196 possibilities? (y or n)

Das Ganze geht auch für Optionen:

journalctl  <TAB>[<TAB>]

Also:

mytux:~ # journalctl  -<TAB>[<TAB>]
--all             --system
--boot            --this-boot
--cursor          --unit
--directory       --until
--disk-usage      --update-catalog
--field           --user
--file            --user-unit
--follow          --verify
--full            --verify-key
--header          --version
--help            -D
--interval        -F
--lines           -a
--list-boots      -b
--list-catalog    -c
--local           -f
--merge           -h
--new-id128       -l
--no-pager        -m
--no-tail         -n
--output          -o
--priority        -p
--quiet           -q
--setup-keys      -u
--since           

 
Wie so oft führen bzgl. eines bestimmten Dienstes bzw. eines korrespondierenden Kommandos mehrere Wege zum Ziel:

mytux:~ # journalctl  _SYSTEMD_UNIT=sshd.service

oder

mytux:~ # journalctl  -u sshd

oder

mytux:~ # journalctl  –unit sshd

und

rux:~ # journalctl  _COMM=sshd

führen zu sehr ähnlichen Outputs. Der letzte Befehl zeigt am meisten an.

“_COMM” steht dabei für “Command” – das ermöglicht natürlich sehr vielfältige Filtermöglichkeiten – je nach Logging-Einstellungen.

Nun kombiniert man den Filter für eine Unit oder ein Komamndo noch mit einer Zeiteinschränkung über die Optionen “–since” und “–until” und jeweiligen Zeitstempeln im Format „2015-06-30 10:13:16“ – und schon fühlt man sich als Admin bzgl. der Analyse etwas besser. Z.B.:

mytux:~ # journalctl -u sshd –since “2015-06-30” –until “today”

Fazit: Durch die Autocompletion-Funktionalität wird einem der Gewöhnungsprozess an “journalctl” doch erheblich erleichtert. Man muss es halt nur wissen – und irgendwann sitzen die Kommando-Optionen auch bei mir.

Links:
https://wiki.archlinux.org/index.php/Systemd
http://0pointer.de/blog/projects/journalctl.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-Using_the_Journal.html
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs