Plesk Bug nach Neustart | Lock Manager Error | Fehlerbehebung | Alfahosting Rettungsmodus
Immer mal wieder kommt es vor, dass man in Plesk / Linux mal einen Neustart machen muss, nichts Neues oder? Doch was ist wenn man völlig routiniert einen Neustart initiiert und anschließend feststellen muss, dass man keinen Zugriff mehr auf die Aministrator-Oberfläche von Plesk hat? Genau das war in einem November Update der Fall. Viele User / Admins erhielten nach einem Neustart die Meldung „[LockManagerException] Can’t open or create shared memory…“ was natürlich erstmal schockiert wenn man kritische Anwendungen hostet.
Auch ich hatte diesen Bug, jedoch liefen bei mir alle Webseiten wie gewohnt weiter und es war wirklich „nur“ das Plesk Dashboard davon betroffen. Ich habe mir wie folgt Abhilfe geschafft, auch ein Zugriff via SSH war so nicht mehr möglich.
Damit wir diesen Fehler beheben können müssen wir ein Aufgabe anlegen, dazu mehr.
Anleitung
Da kein Zugriff mehr über Putty (SSH) mehr möglich war, hatte ich keine andere Wahl als zu einer ruhigen Zeit (Nachts, da kleine Kunden auf dem Server gehostet werden) den Server in den Rettungsmodus zu versetzen. Da meine Server direkt bei Alfahosting gehostet werden ist das relativ komfortabel über den Server-Manager möglich. Meldet euch dazu bei Alfahosting an, wechselt nun in euren Tarif und unter „Rettungssystem“ könnt ihr direkt per SSH auf Dateisystem zugreifen. Sobald man das Rescure System gestartet hat, wird der Server natürlich gestoppt und ist so erstmal nicht mehr erreichbar. Anschließend erhält man die temporären Zugangsdaten für SSH.
Anschließend öffnet Ihr Putty, oder einen anderen SSH-Client und verbindet euch mit dem Server, durch IP oder DNS-Name. Anschließend müsst Ihr euch hier mit euren temporären Zugangsdaten anmelden. Eventuell müsst Ihr nochmal das Zertifikat bestätigen und vertrauen.
Wenn Ihr nun eingeloggt seit, müsstet Ihr je nach Provider auch eine entsprechende Meldung und eventuelle Hinweise erhalten zu dem Rettungsmodus. In der Regel wird das aktuelle Dateisystem unter dem Ordner „repair“ liegen. Um die Cronjob-Datei für den root-User nun zu editieren, bzw. eine Aufgabe anzulegen, müssen wir nun noch in das „Crontabsverzeichnis“ wechseln.
Ich konnte mittels cd repair/var/spool/cron/crontabs/ direkt in den Crontabs-Ordner wechseln. Wenn dieser Ordner nicht vorhanden ist, bitte nicht in Panik ausbrechen sondern er kann auch eine andere Bezeichnung haben, hier dann mit dem Befehl „ls“ zum Auflisten der Objekte arbeiten.
Wenn Ihr nun in dem Crontabs-Ordner seit, öffnet die Datei „root“ mit edit root oder einem anderen Befehl/Editor, hier kann das natürlich je nach Linux/Provider/Custom unterscheiden, auch die Bedienung des Editors ist immer individuell. Wichtig ist nur, dass nun an das Ende der Datei folgender Befehl eingetragen wird:
@reboot mkdir -p /run/lock/lmlib ; chown root:lock-manager /run/lock/lmlib ; chmod -R 0770 /run/lock/lmlib ; mkdir /var/run/sshd ; chmod 0755 /var/run/sshd ; /etc/init.d/ssh restart
Nun speichert noch die Datei ab und startet nun den Server neu und schaltet den Rettungsmodus aus. Bei mir war keine weitere Nacharbeit mehr notwendig, es lief alles wie „geschmiert“. Prüft alle Webhosting-Kunden auf Funktion, verifiziert, dass alle Server/Dienste laufen und am besten sofort nochmal ein Backup starten.
Fazit
Wie für jedes System kann es auch mal bei Plesk vorkommen, dass Updates und Features für Fehler sorgen, Plesk selbst dazu hat auch eine Anleitung veröffentlicht: https://support.plesk.com/hc/en-us/articles/115000224773-Plesk-is-not-accessible-Can-t-open-or-create-shared-memory-by-shm-name
Da der Fehler nur den Admin-Bereich betraf und nicht den Webserver, Mailserver, etc. und Kunden somit uneingeschränkt weiterarbeiten konnten, war es sicherlich nicht der „tragischste“ Fehler, jedoch ein Fehler der einem erstmal vom Sessel haut als Administrator 🙂