Nachdem die Schutzfolie meines Google Pixel recht mitgenommen aussah, musste Ersatz her - und nachdem es den Hersteller der bisher verwendeten Folie wohl nicht mehr gibt, fiel die Wahl auf atFoliX.
Die bestellten Folien trafen auch schnell ein, waren aber leider 2mm zu schmal:
Ein kurzer Mailwechsel mit dem freundlichen Kundenservice reichte und ein paar Tage später lag ein Satz perfekt passender Folien im Briefkasten.
Mit needrestart gibt es für Lunix-basierte Hosts eine Anwendung, die sich in den dpkg,- rpm- oder pacman-Mechanismus einklinkt und nach einer Aktualisierung des Systems mitteilt, ob und welche Systemkomponenten einen Neustart benötigen.
Neben zahlreichen Konfigurationsmöglichkeiten bietet needrestart auch einen Nagios-kompatiblen Ausgabemodus zur Einbindung in das Monitoring-System:
# needrestart -p
OK - Kernel: 6.1.0-22-amd64, Services: none, Containers: none, Sessions: none|Kernel=0;0;;0;2 Services=0;;0;0 Containers=0;;0;0 Sessions=0;0;;0
Checkmk ist in der Lage, über MRPE auch Nagios-kompatible Skripte zu verwenden, allerdings geht es auch einfacher mit Hilfe eines Local Checks:
A local check can be written in any programming language supported by the target host. The script must be constructed so that each check produces a status line consisting of four parts. Here is an example:
0 “My service” myvalue=73 My output text which may contain spaces
Die Skripte werden im Verzeichnis “/usr/lib/check_mk_agent/local/” abgelegt und automatisch vom Agenten mitverarbeitet.
Für needrestart reicht ein kleiner Wrapper, der das Ergebnis des Checks in einen numerischen Status wandelt und die Meldung selbst als Statusdetail ausgibt. Der Dienstname wird auf “needrestart” gesetzt und auf die Übermittlung von Metriken verzichtet.
#!/usr/bin/bash
NEEDRESTART="$(/usr/sbin/needrestart -p)"
if [[ "$NEEDRESTART" =~ ^OK ]]; then
STATE=0
elif [[ "$NEEDRESTART" =~ ^WARN ]]; then
STATE=1
elif [[ "$NEEDRESTART" =~ ^CRIT ]]; then
STATE=2
else
STATE=3
fi
echo "$STATE \"needrestart\" - $NEEDRESTART"
Nachdem das Skript angelegt und ausführbar gemacht wurde, muß auf dem Host nur noch ein Service-Discovery durchgeführt werden damit der neue Service übernommen werden kann.
Auf einem Raspberry Pi hatte ich das Problem, daß ALSA bei jedem Neustart des Systems die Reihenfolge der Ausgabegeräte neu sortierte:
$ cat /proc/asound/cards
0 [Headphones ]: bcm2835_headpho - bcm2835 Headphones
bcm2835 Headphones
1 [PMA50 ]: USB-Audio - PMA-50
D & M Holdings Inc. PMA-50 at usb-3f980000.usb-1.1.3, high speed
2 [vc4hdmi ]: vc4-hdmi - vc4-hdmi
vc4-hdmi
Mal war der PMA-50 als Karte 1 verfügbar, mal wurde ihm die 2 zugewiesen und als Folge daraus war das in der “alsa.conf” festgelegte Ausgabegerät nicht immer das von mir eigentlich gewünschte und der externe DAC blieb stumm.
pcm.!default {
type hw
card 1
}
ctl.!default {
type hw
card 1
}
ALSA kann statt der Nummer der Karte (wie in gefühlt 99% aller Beispiele zu finden) auch deren Namen verwenden werden. Eine Liste aller gültigen Geräte findet sich unter “/proc/asound/”:
$ ls -l /proc/asound/
dr-xr-xr-x 4 root root 0 25. Jun 08:42 card0
dr-xr-xr-x 4 root root 0 25. Jun 08:42 card1
dr-xr-xr-x 8 root root 0 25. Jun 08:42 card2
...
lrwxrwxrwx 1 root root 5 25. Jun 08:42 Headphones -> card0
...
lrwxrwxrwx 1 root root 5 25. Jun 08:42 PMA50 -> card2
...
lrwxrwxrwx 1 root root 5 25. Jun 08:42 vc4hdmi -> card1
...
Nach einer Anpassung der “alsa.conf” funktioniert der USB-DAC unabhängig von der zugewiesenen Gerätenummer:
pcm.!default {
type hw
card PMA50
}
ctl.!default {
type hw
card PMA50
}
Nach dem Update von Debian 11 auf Debian 12 zeigte ein Dell 7280 bei jedem Systemstart kurz die Meldung
[ 0.076930] x86/cpu: SGX disabled by BIOS.
was zu der Frage “Was ist SGX und wer braucht das?” führte.
Bei SGX handelt es sich um die Intel Software Guard Extensions, eine Erweiterung der Prozessorarchitektur, um Programme innerhalb des RAMs voneinander abzuschotten.
Die Erklärung, warum die Meldung nach dem Debain-Update plötzlich ausgegeben wurde, hängt mit dem verwendeten Kernel zusammen: während Bullseye noch mit dem 5.10’er Kernel lief, wird Debian Bookworm mit Kernel 6.xx ausgeliefert - der Support für Intel SGX wurde mit Kernel 5.11 eingeführt.
Seit Prozessor-Genration 11 ist SGX wohl aber wieder Geschichte, denn sowohl in den Core-i-Prozessoren der Generationen 11 als auch 12 fehlten die Software Guard Extensions wieder, was zu Problemen mit sich darauf verlassender Software führt.
Die Extensions können im BIOS mit Hilfe der Option “Intel SGX Enable” aktiviert werden. “Software Controlled” ist hierbei nicht ausreichend, die Option muß auf “Enabled” gesetzt werden, damit der Kernel zufrieden ist.
Nach einem Betriebssystem-Update von Debian 11 auf Debian 12 wollte Torchlight 2, das vor dem Update problemlos lief, nicht mehr starten: nach dem Klick auf das Icon erschien nur noch kurz der Spash-Screen … und das war’s - vom eigentlich erwarteten Startschirm fehlte jede Spur.
Als erste Möglichkeit zur Fehlersuche bietet sich meist ein Start des Programms über die Kommandozeile an, in der Hoffnung, dadurch vielleicht in paar Statusmeldungen zu sehen. Dies funktioniert auch beim Start von Torchlight 2, welches eine ganze Menge an Meldungen ausgab, bevor es letztendlich mit einem “Speicherzugriffsfehler” abbrach.
$ ./Torchlight2.bin.x86_64
Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
...
Loading library RenderSystem_GL
Path for saving is ...
...
Compressing memory size is: 246
Compressing memory size is: 4559
Speicherzugriffsfehler
Leider führte die Kombination von “Torchlight 2” und “Speicherzugriffsfehler” bei der Suche nach Lösungsmöglichkeiten nicht zu hilfreichen Ergebnissen. Auch Tips, die in Richtung von Bibliothekskonflikten gingen halfen nicht, das Programm wieder zum Starten zu bewegen.
Zum Ziel führte letztendlich ein Blick in die Datei “ogre.log”, die auf den ersten Blick identisch mit den Ausgaben beim Programmstart aussieht, allerdings noch ein paar zusätzliche Ausgaben enthält:
$ cat ~/.local/share/Runic\ Games/Torchlight\ 2/ogre.log
11:57:15: Creating resource group General
11:57:15: Creating resource group Internal
11:57:15: Creating resource group Autodetect
...
11:57:15: Loading library RenderSystem_GL
11:57:15: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library RenderSystem_GL. System Error: libGLU.so.1: cannot open shared object file: No such file or directory in DynLib::load at /builddir/Torchlight2/ogre170/OgreMain/src/OgreDynLib.cpp (line 94)
11:57:15: Path for saving is ...
...
11:57:16: Compressing memory size is: 246
11:57:16: Compressing memory size is: 4559
So war der entscheidende Hinweis zwischen den Zeilen “Loading library RenderSystem_GL” und “Path for saving is” versteckt, im konkreten Fall ein
System Error: libGLU.so.1: cannot open shared object file: No such file or directory
der sich durch Installation des Pakets libglu1-mesa letzendlich leicht beheben ließ.