30
Server wiederholt plötzlich nicht mehr erreichbar
Hallo,
ich habe das Problem mit einem Ubuntu (22.04) basierten Linux-Server, dass dieser nahezu täglich "einfriert". Will heißen: Der Server antwortet in diesem Moment nicht mehr auf Anfragen, eine SSH-Verbindung ist nicht mehr möglich und auch eine Verbindung via KVM-Konsole schlägt fehl.
Im SYSLOG erscheinen zum Zeitpunkt des Einfrierens ebenfalls keine direkt aussagekräftigen Informationen:
Beispiel 1 – System friert etwa Dec 21 5:58 Uhr ein:
Dec 21 05:57:20 apps active-protection.sh[674967]: error: cannot open Packages database in /nonexistent/.rpmdb
Dec 21 05:57:20 apps active-protection.sh[674975]: error: cannot open Packages database in /var/lib/Acronis/.rpmdb
Dec 21 05:57:25 apps active-protection.sh[675009]: error: cannot open Packages database in /nonexistent/.rpmdb
Dec 21 05:57:25 apps active-protection.sh[675017]: error: cannot open Packages database in /var/lib/Acronis/.rpmdb
Dec 21 05:57:30 apps active-protection.sh[675128]: error: cannot open Packages database in /nonexistent/.rpmdb
Dec 21 05:57:30 apps active-protection.sh[675136]: error: cannot open Packages database in /var/lib/Acronis/.rpmdb
ich habe das Problem mit einem Ubuntu (22.04) basierten Linux-Server, dass dieser nahezu täglich "einfriert". Will heißen: Der Server antwortet in diesem Moment nicht mehr auf Anfragen, eine SSH-Verbindung ist nicht mehr möglich und auch eine Verbindung via KVM-Konsole schlägt fehl.
Im SYSLOG erscheinen zum Zeitpunkt des Einfrierens ebenfalls keine direkt aussagekräftigen Informationen:
Beispiel 1 – System friert etwa Dec 21 5:58 Uhr ein:
Dec 21 05:57:20 apps active-protection.sh[674967]: error: cannot open Packages database in /nonexistent/.rpmdb
Dec 21 05:57:20 apps active-protection.sh[674975]: error: cannot open Packages database in /var/lib/Acronis/.rpmdb
Dec 21 05:57:25 apps active-protection.sh[675009]: error: cannot open Packages database in /nonexistent/.rpmdb
Dec 21 05:57:25 apps active-protection.sh[675017]: error: cannot open Packages database in /var/lib/Acronis/.rpmdb
Dec 21 05:57:30 apps active-protection.sh[675128]: error: cannot open Packages database in /nonexistent/.rpmdb
Dec 21 05:57:30 apps active-protection.sh[675136]: error: cannot open Packages database in /var/lib/Acronis/.rpmdb
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 54016269159
Url: https://administrator.de/contentid/54016269159
Ausgedruckt am: 24.11.2024 um 01:11 Uhr
30 Kommentare
Neuester Kommentar
Hallo, bitte was ist nicht aussagekräftig?
Acronis. Was ist das dort? Backup Agent? Backup des Servers oder arbeitet es als Agent und sichert noch andere VMs?
CyberBackup oder Standalone?
Mal das Ding deinstalliert und re-deployed? Bzw. ohne Acronis mal ein paar Stunden getestet?
mfg Crusher
Acronis. Was ist das dort? Backup Agent? Backup des Servers oder arbeitet es als Agent und sichert noch andere VMs?
CyberBackup oder Standalone?
Mal das Ding deinstalliert und re-deployed? Bzw. ohne Acronis mal ein paar Stunden getestet?
mfg Crusher
Danke für Deine Rückmeldung, @Crusher79.
Hatte Acronis auch als »Ursache« im Verdacht. Doch ein Support-Call dort hat (bislang) keine Idee gebracht. Denn Acronis wird auf dem Server als Backup Agent für Linux eingesetzt (Datei-/Ordner-Backup, kein Image-Backup).
Insofern: Danke für den KB-Artikel von Acronis … aber: Heißt das – auch wenn hier die Meldung lautet dass ich dennoch die folgenden Kommandos absetzen soll?
Viele Grüße.
Hatte Acronis auch als »Ursache« im Verdacht. Doch ein Support-Call dort hat (bislang) keine Idee gebracht. Denn Acronis wird auf dem Server als Backup Agent für Linux eingesetzt (Datei-/Ordner-Backup, kein Image-Backup).
Insofern: Danke für den KB-Artikel von Acronis … aber: Heißt das – auch wenn hier die Meldung lautet
cannot open Packages database in /var/lib/Acronis/.rpmdbmkdir /tmp/bak
cp -r /var/lib/rpm/ /tmp/bak/
rm -f /var/lib/rpm/__db*
rpmdb --rebuilddbViele Grüße.
Das räumt nur die DB und Pakete woanders hin.
Was tut denn Acronis da überhaupt? Application aware Backup? Backup Agent nur so? Virtuelle Maschine? Welche Acronis Version?
Ansonsten das Ding mal komplett deaktivieren. Du kannst auch CPU Auslastung und Netzwerkauslastung beim Backup normal angeben. Ggf. hier auch mal Acronis etwas zurück nehmen.
Ansonsten komplett runterschmeißen und kurz beobachten.
Was tut denn Acronis da überhaupt? Application aware Backup? Backup Agent nur so? Virtuelle Maschine? Welche Acronis Version?
Ansonsten das Ding mal komplett deaktivieren. Du kannst auch CPU Auslastung und Netzwerkauslastung beim Backup normal angeben. Ggf. hier auch mal Acronis etwas zurück nehmen.
Ansonsten komplett runterschmeißen und kurz beobachten.
Acronis führt stündlich ein Backup von Dateien und Ordnern auf dem Server durch. Das dauert immer ca. 3 Minuten und ist nicht zu dem Zeitpunkt aktiv, wo der Server "einfriert" – daher gehe ich davon aus, dass das Backup selbst keine Auswirkungen hat. Der installierte Agent for Linux ist aktuell und hat die Version 23.11.36791
Naja Metadaten sammeln, Katalog aktualisieren. Du weißt schon, dass Acronis auch eigene Task vor und nach dem Backups macht? Oft auch einige Zeit später.
Tja so wie sie selbst schreiben
https://www.acronis.com/de-de/technology/active-protection/
Wenn das Schlangenöl sich als Backup-Agent auf die Kisten schmuggelt...
So ein Schlangenöl-Murks hat auf einem Linux Server nichts verloren, selbst Winblows haben die ja nicht im Griff . Wenn ich das hier schon lese stellen sich mir die Haare, und das im laufenden Betrieb ...💩
Da kann man nur Frohe Weihnachten wünschen 🍻
https://www.acronis.com/de-de/technology/active-protection/
Acronis hat die Welt auf den Kopf gestellt
🤪🤪🚑Wenn das Schlangenöl sich als Backup-Agent auf die Kisten schmuggelt...
So ein Schlangenöl-Murks hat auf einem Linux Server nichts verloren, selbst Winblows haben die ja nicht im Griff . Wenn ich das hier schon lese stellen sich mir die Haare, und das im laufenden Betrieb ...💩
Finished Remount Root and Kernel File Systems.
Da kann man nur Frohe Weihnachten wünschen 🍻
1
Kannst du mal was zur Hardware sagen?
Wenn as Remote Management (ich nehme an, das meinst du mit KVM), dann hat das OS damit wenig zu tun.
Wenn as Remote Management (ich nehme an, das meinst du mit KVM), dann hat das OS damit wenig zu tun.
Kurz zu den Hinweisen in Bezug auf Acronis: Zwar gibt es die Hinweise a la "cannot open Packages database in /var/lib/Acronis/.rpmdb«, aber diese scheinen (ich sage nicht, dass es zwingend so ist, sondern nur "scheinen") keinen Zusammenhang mit dem geschilderten Problem zu haben. Zum einen habe ich auf einem anderen unserer Server geschaut, der ohne Probleme läuft und da stehen dieselben Hinweise im syslog, zum anderen habe ich nun deinstalliert, installiert, backup erstellt etc. ohne Probleme oder Einfrieren.
Die Hardware: Es ist ein Dedicated Server (12 Core x 3.1 GHz AMD Ryzen 9 Pro 3900, 128 GB RAM, 2 x 960 GB Software RAID 1). Er steht in einem RZ und ich komme entweder per SSH drauf oder – wenn das nicht möglich ist – via virtueller KVM-Konsole, die der Hoster anbietet. Sie sollte selbst dann erreichbar sein, wenn man per SSH nicht mehr auf den Server kommt. Aber: Ein Zugriff via KVM ist im Fehlerfall auch nicht möglich.
Die Hardware: Es ist ein Dedicated Server (12 Core x 3.1 GHz AMD Ryzen 9 Pro 3900, 128 GB RAM, 2 x 960 GB Software RAID 1). Er steht in einem RZ und ich komme entweder per SSH drauf oder – wenn das nicht möglich ist – via virtueller KVM-Konsole, die der Hoster anbietet. Sie sollte selbst dann erreichbar sein, wenn man per SSH nicht mehr auf den Server kommt. Aber: Ein Zugriff via KVM ist im Fehlerfall auch nicht möglich.
Hi.
Hardware-,Fehler hast du bereits ausgeschlossen?
..HDD/SSD getauscht?
- Treiber überprüft/aktualisiert?
- HDD/SSD- Anschluss gewechselt?
Was sagt das SMART zu HDD/SSD?
Wie sind die Temperaturen der ASD, speziell wenn M.2?
Bios/UEFI kontrolliert? (PCIE-Geschwindigkeit, etc.)
Gehen dem Einfrieren große Datentransfers voraus, also erhöhte Wärmeentwicklung - speziell M.2
Hardware-,Fehler hast du bereits ausgeschlossen?
..HDD/SSD getauscht?
- Treiber überprüft/aktualisiert?
- HDD/SSD- Anschluss gewechselt?
Was sagt das SMART zu HDD/SSD?
Wie sind die Temperaturen der ASD, speziell wenn M.2?
Bios/UEFI kontrolliert? (PCIE-Geschwindigkeit, etc.)
Gehen dem Einfrieren große Datentransfers voraus, also erhöhte Wärmeentwicklung - speziell M.2
Ja, Hardware Fehler wurden keine gefunden; System ist "up-to-date". Es gibt zu den Zeitpunkten des "Einfrierens" keine anormalen Datentransfers. Der Server wird als Webserver genutzt und hat keine spezifische Last.
OK.
Dennoch könnten Hardware-Fehler das Problem sein, neben HDD/SSD auch CPU und RAM ...
.. auch GPU, BIOS oder schwankende Stromversorgung (Netzteil) können sowas verursachen - neben vielen anderen ...
Dennoch könnten Hardware-Fehler das Problem sein, neben HDD/SSD auch CPU und RAM ...
.. auch GPU, BIOS oder schwankende Stromversorgung (Netzteil) können sowas verursachen - neben vielen anderen ...
Natürlich kann man einen Hardware-Fehler nie ausschließen, aber: Eine erste Frage wäre dann, ob ich den Problemkreis zielsicher(er) durch Logs o.ä. die ich noch nicht geprüft habe, einschränken könnte. Denn physisch komme ich nicht an das Gerät (Hoster).
Wenn es ein Hardware-Problem ist, hat das OS ggf. gar keine Zeit etwas zu loggen ...
Steht irgendwas im Log von der Remote-Management Console?
Welches Mainboard hat der Server ?
Unter Linux:
Welches Mainboard hat der Server ?
Unter Linux:
sudo ipmitool sel list
Nein, von der Remote-Management Console gab es nix im Log. Hier die Info zum Mainboad:
Manufacturer: ASRockRack
Product Name:X470D4U2/1N1
Manufacturer: ASRockRack
Product Name:X470D4U2/1N1
Löst sich das Problem nach 10 Minuten von alleine, oder musst du die Maschine hart neustarten?
Ich würde prüfen, ob es über die KVM-Konsole möglich ist, Sysrq-Tastenkombinationen (also z.B. Alt+Druck+H) an das System zu senden (vorher ggf. über /proc/sys/kernel/sysrq aktivieren). Wenn das verifiziert ist und das System das nächste Mal hängt kannst du darüber zumindest Hardwaredefekte ausschließen (wenn das System darauf noch reagiert) und anhand der Ausgabe auch häufig Ursachen feststellen (z.B. sehr viele Prozesse gestartet, SWAP zu 100% voll, oder alle Prozessoren hängen gerade in einem Kerneltreiber der zu Schlangenöl aka Endpoint Protection gehört). Möglicherweise kannst du den bösen Prozess sogar abschießen oder zumindest die Syslogs auf die Platte flushen, um nachher die Fehlersuche zu erleichtern.
Alternativ bieten viele Remote-Managementkarten auch die Möglichkeit einen NMI (Non Maskable Interrupt) zu erzeugen, der dafür sorgt dass der Kernel (wenn korrekt konfiguriert) mit einer Panic stehen bleibt und im besten Fall Informationen über das was er gerade tut ausgibt. Ist im vergleich zu Sysrq (was das System grundsätzlich weiterlaufen lässt und wo man mit den Tasten die man drückt Einfluss nehmen kann welche Informationen man sehen will) die rabiatere Methode, wenn Sysrq aber nicht möglich ist oder nicht zum Erfolg führt, ist es sicher einen Versuch wert. Insbesondere wenn der Server sich sowieso nicht berappelt und neu gestartet werden muss.
Ich würde prüfen, ob es über die KVM-Konsole möglich ist, Sysrq-Tastenkombinationen (also z.B. Alt+Druck+H) an das System zu senden (vorher ggf. über /proc/sys/kernel/sysrq aktivieren). Wenn das verifiziert ist und das System das nächste Mal hängt kannst du darüber zumindest Hardwaredefekte ausschließen (wenn das System darauf noch reagiert) und anhand der Ausgabe auch häufig Ursachen feststellen (z.B. sehr viele Prozesse gestartet, SWAP zu 100% voll, oder alle Prozessoren hängen gerade in einem Kerneltreiber der zu Schlangenöl aka Endpoint Protection gehört). Möglicherweise kannst du den bösen Prozess sogar abschießen oder zumindest die Syslogs auf die Platte flushen, um nachher die Fehlersuche zu erleichtern.
Alternativ bieten viele Remote-Managementkarten auch die Möglichkeit einen NMI (Non Maskable Interrupt) zu erzeugen, der dafür sorgt dass der Kernel (wenn korrekt konfiguriert) mit einer Panic stehen bleibt und im besten Fall Informationen über das was er gerade tut ausgibt. Ist im vergleich zu Sysrq (was das System grundsätzlich weiterlaufen lässt und wo man mit den Tasten die man drückt Einfluss nehmen kann welche Informationen man sehen will) die rabiatere Methode, wenn Sysrq aber nicht möglich ist oder nicht zum Erfolg führt, ist es sicher einen Versuch wert. Insbesondere wenn der Server sich sowieso nicht berappelt und neu gestartet werden muss.
Da der Server ziemlich sicher via 2 Stromkabeln redundant versorgt wird (von dem eins hoffentlich an der USV hängt) würde ich Stromprobleme ausschliessen.
Abgesehen davon würden die im Log vom KVM/IPMI/BMC/remote management stehen.
Mich macht immer noch die Aussage stutzig, dass während dieser Zeit die Remote-Management (KVM) nicht erreichbar ist. Diese sind (bis auf die Stromversorgung) komplett unabhängig vom System (Komplett eigener Computer auf ARM Basis, vergleichbar mit einem Raspberry).
In den Logs des Remote-Management müsste auch stehen, wann die Remote-Managementö-Console gebootet wurde.
Wie bringst du den Rechner überhaupt wieder zum Leben, wenn du weder per SSH noch per Remote-Management etwas machen kannst?
Abgesehen davon würden die im Log vom KVM/IPMI/BMC/remote management stehen.
Mich macht immer noch die Aussage stutzig, dass während dieser Zeit die Remote-Management (KVM) nicht erreichbar ist. Diese sind (bis auf die Stromversorgung) komplett unabhängig vom System (Komplett eigener Computer auf ARM Basis, vergleichbar mit einem Raspberry).
In den Logs des Remote-Management müsste auch stehen, wann die Remote-Managementö-Console gebootet wurde.
Wie bringst du den Rechner überhaupt wieder zum Leben, wenn du weder per SSH noch per Remote-Management etwas machen kannst?
Ich hatte den OP so verstanden, dass das KVM als solches schon noch erreichbar ist, aber der Server auf Aktionen der KVM-Konsole nicht mehr reagiert (sich der vom KVM angezeigte Bildschirminhalt beim Tippen auf die virtuelle Tastatur nicht ändert). Wenn dem nicht so ist, und das Management selbst nicht mehr funktioniert, kannst du meinen Beitrag ignorieren.
Zitat von @BrainyBeacon:
Kurz zu den Hinweisen in Bezug auf Acronis: Zwar gibt es die Hinweise a la "cannot open Packages database in /var/lib/Acronis/.rpmdb«, aber diese scheinen (ich sage nicht, dass es zwingend so ist, sondern nur "scheinen") keinen Zusammenhang mit dem geschilderten Problem zu haben. Zum einen habe ich auf einem anderen unserer Server geschaut, der ohne Probleme läuft und da stehen dieselben Hinweise im syslog, zum anderen habe ich nun deinstalliert, installiert, backup erstellt etc. ohne Probleme oder Einfrieren.
Die Hardware: Es ist ein Dedicated Server (12 Core x 3.1 GHz AMD Ryzen 9 Pro 3900, 128 GB RAM, 2 x 960 GB Software RAID 1). Er steht in einem RZ und ich komme entweder per SSH drauf oder – wenn das nicht möglich ist – via virtueller KVM-Konsole, die der Hoster anbietet. Sie sollte selbst dann erreichbar sein, wenn man per SSH nicht mehr auf den Server kommt. Aber: Ein Zugriff via KVM ist im Fehlerfall auch nicht möglich...
Kurz zu den Hinweisen in Bezug auf Acronis: Zwar gibt es die Hinweise a la "cannot open Packages database in /var/lib/Acronis/.rpmdb«, aber diese scheinen (ich sage nicht, dass es zwingend so ist, sondern nur "scheinen") keinen Zusammenhang mit dem geschilderten Problem zu haben. Zum einen habe ich auf einem anderen unserer Server geschaut, der ohne Probleme läuft und da stehen dieselben Hinweise im syslog, zum anderen habe ich nun deinstalliert, installiert, backup erstellt etc. ohne Probleme oder Einfrieren.
Die Hardware: Es ist ein Dedicated Server (12 Core x 3.1 GHz AMD Ryzen 9 Pro 3900, 128 GB RAM, 2 x 960 GB Software RAID 1). Er steht in einem RZ und ich komme entweder per SSH drauf oder – wenn das nicht möglich ist – via virtueller KVM-Konsole, die der Hoster anbietet. Sie sollte selbst dann erreichbar sein, wenn man per SSH nicht mehr auf den Server kommt. Aber: Ein Zugriff via KVM ist im Fehlerfall auch nicht möglich...
Ich habe über google deinen Eintrag gefunden. Kann es sein das es ein Ionos AR12-128 Server mit Ubuntu 22.04 ist? Ich habe nun bereits den 4. - alle haben genau das Fehlerbild, alle paar Tage - meist so nach 7-14 Tagen "friert" der Server komplett ein. KVM Konsole ist schwarz, nur ein reboot über das Cloudpanel hilft. Ein anderer AR8-64 mit dem selben Image (bzw. eben auch Ubuntu 22.04) läuft seit der Neuinstallation ebenfalls Mitte Dezember ohne Probleme. Alle neuen AR12-128 die ich konfiguriert habe zwischen Mitte Dezember und jetzt spacken aber... In den Logs ist bei mir nichts zu finden, ich nutze aber auch kein Acronis mehr, alles schon versucht.... Reboot über die Cloudkonsole und der Server läuft SOFORT wieder einige Tage, wshalb ich Strom, Kabel, Switch usw. ausschließe.... alles probiert, cloud init (das wohl wegen der VServer auch bei den Dedicated in den Images ist..) deaktiviert, IPv6 deaktiviert, mit stress-ng getestet, ram test usw.... keine Fehler... total strange und Ionos hat auch keine Idee...
@n0fear Du hast den sprichwörtlichen Nagel auf den Kopf getroffen. Genau so ist es – leider.
Zitat von @BrainyBeacon:
@n0fear Du hast den sprichwörtlichen Nagel auf den Kopf getroffen. Genau so ist es – leider.
@n0fear Du hast den sprichwörtlichen Nagel auf den Kopf getroffen. Genau so ist es – leider.
In dem Fall hast du auch noch keine Lösung?
Hat sonst jemand noch eine Idee woran das liegen könnte? heute wieder 17.50 Uhr eingefroren, der andere Server selbe Hardware vorgestern um 6.15 Uhr...
Nein, ich habe auch noch keine Lösung – leider.
Ich hatte eben nochmal Kontakt mit Ionos, ein sehr kompetenter Mitarbeiter, er hat mal recherchiert und wohl mehrere aktuelle Tickets gefunden, die alle die selben Probleme haben, alle mit dem AR 12-128 Ubuntu 22.04 und ein weiteres Ticket ans Rechenzentrum gemacht. Ich habe einen solchen Testserver nun seit Tagen im "Eingefrohren" Status mal stehen lassen. Habe nun die Hoffnung, dass da mal einer mit Monitor hin geht und mal schaut was das Teil anzeigt, ob es überhaupt was anzeigt. Da das Mainboard das selbe ist wie beim AR 8-64 der läuft, nur das Bios unterschiedlich und der Prozessor (+ natürlich mehr ram) gehe ich mal von nem Problem mit dem speziellen Prozessor mit diesem Board aus, das wäre zumindest meine Vermutung. Irgendwo hatte ich auch gelesen, dass manche AMD Prozessoren ein Bios update brauchen. Dran bleiben...
@BrainyBeacon Ist deiner wieder eingefroren oder hat sich was verbessert? Ein Testserver 12/128 hat gestern die komplette Hardware getauscht bekommen, nach wenigen Stunden war er wieder eingefroren....
@BrainyBeacon oder auch andere. Problem wurde wohl laut Ionos Support nun gefunden. Wie ich vermutet hatte liegt es am Bios, die anderen AR Server haben eine andere Biosversion. Es soll nun ein Biosupdate geben, welches das Problem behebt. Meine Server sind am Montag dran, schauen wir mal.
@n0fear, das klingt sehr interessant und ich bin gespannt, was es bringt. Bitte halte mich hier mal auf dem Laufenden, denn bei mir hat sich weder im IONOS-Ticket noch sonst wo etwas getan. Danke.
Ich kann dir nur empfehlen den Support anzurufen und dort Druck zu machen. Bios Update ist drauf, ein neues Bios von 2024 laut Console. Hatte nun die Hoffnung es hat das Problem gelöst. Leider ist der Server eben wieder eingefroren, selbes Bild wie seit 3 Monaten. Ich habe langsam die Nase voll...
Falls sonst noch jemand solche Probleme hat, es scheint weiterhin bei Ionos nicht gelöst zu sein.... Habe vor 4 Wochen auf den AR16-128 getauscht. Dieser läuft stabil. Wer bei dem AR16-128 (wäre ja schön wenn mal alles einfach so läuft) Probleme mit der eth0:0 also 2. IP Adresse hat, auch hierfür ein workaround:
nano /usr/lib/systemd/system/ifupdown-pre.service
Zeile mit udevadm auskommentiert
#ExecStart=/bin/sh -c 'if [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && [ -x /bin/udevadm ]; then udevadm settle; fi'
schon hängt systemctl restart networking nicht mehr.
nano /usr/lib/systemd/system/ifupdown-pre.service
Zeile mit udevadm auskommentiert
#ExecStart=/bin/sh -c 'if [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && [ -x /bin/udevadm ]; then udevadm settle; fi'
schon hängt systemctl restart networking nicht mehr.
