nachfolgend wollte ich meine Erfahrung mit perfctl teilen.
In letzter Zeit hatte ich beim Login in Keyhelp eine CPU Auslastung von über 100% angezeigt bekommen. Das war sehr ungewöhnlich, da der Server recht großzügig bemessen ist. Also auf den Server gehängt und dort nur eine normale Auslastung >10% festgestellt. Ich hab das dann (leider) nicht weiter beachtet. Ein paar Tage später sind dann immer wieder IMAP und SMTP ausgestiegen. Dabei habe ich dann festgestellt, dass das syslog und eine deamon.log die ganze Platte gefüllt hat (jeweils >60GB).
Jetzt muss ich zugeben, dass ich noch auf Debian 11 lief und dachte, dass ein Upgrade auf die 12 sicherlich Abhilfe schafft. Also hab ich das offizielle Skript angeschmissen und alles lief wunderbar durch. Ein Neustart wurde dann wie erwartet gefordert. Und da ging die Sauerei los. Das System hing im Kernel-Panic fest.
Folgendes habe ich dann herausgefunden:
Mit einem Live-Image konnte ich dann erstmal wieder meine Volumes mounten und hatte so Zugriff auf meine Daten. Mit update-initramfs wollte ich den Fehler beim booten abschaffen, aber der ist immer in einen Fehler gelaufen: E: /usr/share/initramfs-tools/hooks/fsck failed with return 1. Ein Abfragen nach den Abhängigkeiten mit ldd /sbin/fsck.ext4 hat offenbart, dass eine "ungewöhnliche" Lib mit drinhing: /lib/libgcwrap.so. Diese ist Teil des perfctl/perfcc Crypto Miners.
Das perfide ist, dass /lib/libgcwrap.so als immutable deklariert ist und im Dateisystem nicht zu sehen ist. Nur durch den Blick von außen mit dem Live-Image konnte man es finden und dann auch entfernen. Der Miner hat auch neue Symlinks zu top etc gesetzt, so dass er sich beim genaueren Hinsehen direkt deaktiviert. Daher war er auch beim Blick in die Shell nicht zu finden. Einen Cron-Job für root hat er auch angelegt.
Nach ein paar Aufräumarbeiten konnte ich dann mit dem Live-Image die Kernel zwar nicht reparieren, aber wenigstens das Bootloader-Timeout deaktivieren, so dass ich mit dem älteren Debian 11 Kernel booten konnte. Die Dienste liefen auch (fast) alle wieder an.
Backups waren natürlich gemacht. Ich habe auch die Möglichkeit genutzt, um nochmal frisch die laufenden Docker Volumes zu sichern. Danach wurde alles platt gemacht und frisch installiert.
Dickes Danke an Keyhelp für die hervorragende Möglichkeit, Backups wieder einzuspielen.
Wie es zu der ganzen Geschichte kommen konnte, ist mir abschließend nicht wirklich klar. Einige Stimmen deuten auf den Portainer-Agent, der es möglich macht die Docker-Umgebung von außen zu steuern. Aber genau weiß ich es nicht.
Es gibt insgesamt wenige Infos im Netz zu perfctl. Deswegen dachte ich, ergibt es evtl. Sinn das zu teilen.
Ich habe nun Tailscale im Einsatz, um einen direkten Zugriff auf die Maschine zu haben. Läuft ganz wunderbar und kann ich nur empfehlen.
PS: Da ich kein Sysadmin bin, habe ich an manchen Stellen vermutlich nicht optimal gehandelt. Aber im Ergebnis läuft jetzt alle wieder reibungslos
Links:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1641230 Kommentar 15
https://bugs.launchpad.net/ubuntu/+sour ... ug/2057605
