Plesk-Bugs – 100% CPU sbin/init – Resolution

Plesk-Bugs im Parallels Plesk-Panel - 100% CPUImmer öfter mußten wir feststellen, daß Plesk plötzlich aus heiterem Grund extrem ausgelastet war mit 100% CPU (Plesk-Bugs) ohne eigentlich was abarbeiten zu müssen! Selbst die Beschränkungen mittel cGroup brachten keine Erfolge, bis wir dann aber darüber gefallen sind, daß 2 alte Plesk-Bugs zu diesen Problemen führen! Und wir haben auch Workarounds erarbeitet, die diese Problem beseitigen!

Der Hauptgrund für die Problematik sind Nameserver-Abfragen von den Haupnameservern (privilegierten) auf Zonen, die gar nicht (oder nicht mehr) existieren, denn es scheint kein Einzelfall zu sein, daß Plesk bei Löschung einer Domain, die DNS-Zonen nicht sauber löscht! Ggf. liegt hier ein Programmfehler in der Abfrage vor, denn ein Workarround von Plesk für ein manuelles Bereinigen führt nämlich ebenfalls ins Leere, also einer Nichtlöschung der nicht konsistenten Datenbank-Einträge für die DNS-Zonen und Einträge, weil nicht auf jedem Server auch für eine IP eine Standard-Domain gesetzt ist und es auch nicht so sein muß! Daß auch nicht nur von uns diese Probleme erkannt wurden, sieht man daran, daß bei dem Workarround, der bei Plesk veröffentlicht wurden, bereits mehrere User diese als „guten Artikel“ markiert haben, obwohl dieser selbst ein paar Tage alt ist – allerdings hat deren Workarround neue Fehler drin!

Beim 2. Problem, daß ebenfalls Grund ist, wurden früher in den Vorversionen von Plesk in den DNS-Templates PTR-Records angeboten, was wir bereits im Jahre 2013 in unserem Wiki im Artikel Ungünstige MX-Records (Plesk) geschrieben hatten. Inzwischen hat Plesk sowohl die Problematik der Mail-Server extrem verbessert und PTR wird nicht mehr als Vorgabe in den DNS-Templates bereit gestellt! Wenn jedoch historisch gewachsen (Plesk 11.5/12.0/12.5/17.x etc), jemals mit den alten Templates diese PTR-Records in die DNS-Zonen eingetragen wurden, so wurden diese spätestens dann zum Problem, wenn irgendwann bei der Domain eine IP-Änderung sich ergeben hat! Dann blieb also bei der Domain der alte PTR-Record enthalten, der auch überhaupt nicht benötigt wird, aber der dann intern in Plesk eine ARPA-Zone erzeugt!

In beiden Fällen werden also immer wieder neu, aufgrund veralteter DNS-Einträge DNS-Zonen erzeugt, für die der Server aber keine Domains mehr hat! Folglich führen dann Nameserver-Abfragen der privilegierten Nameserver dazu, daß es zu Abweisungen (denied´s) kommt und dann von den Nameservern die Anforderung, aufgrund zu vieler Fehler kommt, die Nameserver-Zonen neu aufzubauen! (Fehlermeldung: received control channel command ‚reload‘ –
zu finden in der daemon.log). Wenn dies dann alle 1 Minute oder alle 5 Minuten erfolgt, dann ist dies schon eine Belastung – offensichtlich kommt es dann auch beim Laden zu Fehlern, wie die Zonen-Datei existiert nicht usw!

Workarround ist also, die Daemon.log zu untersuchen:

grep 'control channel' /var/log/daemon.log
grep 'denied' /var/log/daemon.log

Im 2. Schritt ist zu klären, ob es veraltete ARPA-Zonen-Files gibt und die Ursache in den PTRs liegt. Dazu:

cd /var/named/run-root/var
grep 'PTR' *

Im 3. Schritt ist zu prüfen, ob sich VERALTETE Zonen – Files in /var/named/run-root/var befinden und diese in /etc/named.conf eingetragen sind!

Zur Bereinigung. Hier verweisen wir auf einen Plesk-Artikel, der sich mit der Löschung der DNS-Zonen und Einträge, der nicht konsistenten Plesk-Datenbank beschäftigt! Siehe Plesk-Artikel
DNS server of Plesk does not work properly !
Da aber auch hier die Anweisungen vom Plesk-Team, nicht sauber sind, haben wir diese dort kommentiert und führen hier, die Einzelschritte auf (ohne Gewähr), wie Sie diese DNS-Einträge bereinigen können:

The Delete – SQL is wrong, why on many servers the default_dns_zone is not set and then the subquery brings NULL (about empty result) and will an <> operator not work!

So make it better and check before whats DNS-Zones are not deleted before:

select id,name from dns_zone where id not in (select dns_zone_id from domains) and id not in (select dns_zone_id from domain_aliases)
and id not in (select val from misc where param = 'default_dns_zone_id');

In next step you can delete then the DNS-Zones with:

delete from dns_zone where id not in (select dns_zone_id from domains) and id not in (select dns_zone_id from domain_aliases)
and id not in (select val from misc where param = 'default_dns_zone_id');

UND:

again must been controlled:

select id,host from dns_recs where dns_zone_id not in (select dns_zone_id from domains) and dns_zone_id not in (select dns_zone_id from domain_aliases)
and dns_zone_id not in (select val from misc where param = 'default_dns_zone_id');

and then deleted:

delete from dns_recs where dns_zone_id not in (select dns_zone_id from domains) and dns_zone_id not in (select dns_zone_id from domain_aliases)
and dns_zone_id not in (select val from misc where param = 'default_dns_zone_id');

Von uns dann noch zugesetzt:

SELECT * FROM dns_recs WHERE type = 'PTR'; 

müssten alle Sätze anzeigen, die auch mit grep ‚PTR‘ in /var/named/run-root/var gefunden werden!

PTR-Records sind die sogenannten DNS-Reverse-Records und diese werden eigentlich grundsätzlich nur über die DNS-Verwaltung der IP-Zonen gesetzt und können nicht mit den Domains gesetzt werden! Also sind diese PTR-Records in den Domains sinnlos!

Bevor Sie aber die Löschung in Plesk durchführen, sollten Sie sich besser system-intern mit dem Thema beschäftigen, ob dies auch für Ihre DNS-Verwaltung so gilt!

Wenn Sie sicher sind, daß Sie wie üblich, die PTRs nicht benötigen, dann können Sie und sollten Sie sogar, diese löschen mit:

DELETE FROM dns_recs WHERE type = 'PTR'; 

Zu letzt müssen Sie natürlich dafür sorgen, daß die /etc/named.conf und die DNS-Zonen-Files sauber erzeugt werden! Dazu erzeugen Sie sich bitte folgendes Script. Es stammt von Plesk (als Urheber)  und ist ein Hilfsscript, daß für jede Domain das Script dnsmng –update {Domain} anstößt:


#!/bin/sh

ADMIN_PASS=`cat /etc/psa/.psa.shadow`
MYSQL_BIN_D=`grep MYSQL_BIN_D /etc/psa/psa.conf | awk '{print $2}'`
PRODUCT_ROOT_D=`grep PRODUCT_ROOT_D /etc/psa/psa.conf | awk '{print $2}'`
mysql="${MYSQL_BIN_D}/mysql -Ns -uadmin -p${ADMIN_PASS} -Dpsa"

query="select name from dns_zone"
domains=`echo $query | $mysql`

for i in ${domains}; do
echo "$i"
$PRODUCT_ROOT_D/admin/sbin/dnsmng --update $i
done 

Danach führen Sie am besten auch folgendes Repair-Programm noch aus:

plesk repair dns

Dieser läuft beim ersten Durchlauf sehr lange, also kann schon ne Stunde dauern, aber keine Angst, der Server läuft normal weiter!

Wenn während des Prozesses Probleme gefunden werden, prüfen Sie manuell noch mal die Datenbank-Einträge und wenn ggf. löschen Sie manuell aus /etc/named.conf die überflüssigen Einträge (also auch die ARPA-Einträge raus löschen) raus!

Es ist kein Problem, in der named.conf die überflüssigen DNS-Zonen zu löschen, aber ist die Datenbank nicht sauber, weil z.B. alte DNS-Zonen noch bestehen, wird die named.conf und natürlich auch die DNS-Zonen-Files von Plesk wieder neu erzeugt!

Wenn wir mit allem fertig sind, müssen wir den Nameserver von Plesk noch neu starten, mit

service bind9 stop
service bind9 start

Was passiert danach?

Wenn der Nameserver (des internen Plesk-Servers) neu geladen wird, liest er die named.conf Datei und nur wenn hier die DNS-Zonen enthalten sind, werden die DNS-Zonen-Files auf /var/named/run-root/var geladen!

Der von Ihnen verwendete Update-Mechanismus für die privilegierten Nameserver, denn Sie brauchen ja immer mindestens 2, besser 3, erben ja die DNS-Zonen und fragen für die Aktualisierungen dann nur die DNS-Zonen regelmäßig ab, die existieren!

Traurig ist, daß diese Plesk-Bugs schon lange Zeit bestehen

und Plesk nicht dafür sorgt, z.B. im Configruations-Trouble-Shouter (kostenlose Erweiterung), hier die von ihnen selbst erzeugten Datenbank-Inkonsistenzen zu beseitigen! Der Support von Plesk ist auch für Server-Betreiber extrem unwirtschaftlich und schlecht erreichbar! Man möchte nach wie vor, daß man selbst für Plesk-Fehler Geld zahlt, um direkt von Plesk Support zu erhalten! Auch sind immer noch diverse Bugs offen, um die wir diverse Lösungen entwickelt haben, um diese zu umshiften! Dennoch ist Plesk das weltweit meist eingesetzte Webhosting-Administrations-Werkzeug! Auch ist cPanel leider keine Alternative zu Plesk! Wir können alle nur hoffen, daß irgendwann mal bessere Hosting-Lösungen entwickelt werden, wie ehemals Confixx!

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert