Täglicher Crash um 6:25

[divepit]

Hallo zusammen,

Seit einiger Zeit crasht mein vServer, Ubuntu 16.04.5 LTS‬, täglich um 6:25 beim Ausführen der daily cronjobs. Ich bin noch relativ neu in der Webserver Geschichte und weiss deshalb nicht wirklich wie ich das lösen kann.

Die letzten paar Linien im Syslog vor dem Crash sehen so aus:

Nov 4 06:22:01 dpit CRON[11489]: (root) CMD (/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/xovi/scripts/seo-kpi.php')
Nov 4 06:22:33 dpit plesk sendmail[11515]: handlers_stderr: PASS
Nov 4 06:22:33 dpit plesk sendmail[11515]: PASS during call 'limit-out' handler
Nov 4 06:22:34 dpit check-quota[11517]: Starting the check-quota filter...
Nov 4 06:22:34 dpit plesk sendmail[11515]: handlers_stderr: SKIP
Nov 4 06:22:34 dpit plesk sendmail[11515]: SKIP during call 'check-quota' handler
Nov 4 06:25:01 dpit CRON[11589]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Nov 4 06:25:01 dpit CRON[11590]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))

Heute Morgen ist er dann etwas später nochmal gecrasht mit den folgenden letzten Linien:

Nov 4 08:55:08 dpit postfix/smtpd[11808]: disconnect from unknown[41.215.208.138] helo=1 auth=0/1 quit=1 commands=2/3
Nov 4 08:57:01 dpit CRON[12052]: (root) CMD ([ -x /opt/psa/admin/sbin/backupmng ] && /opt/psa/admin/sbin/backupmng >/dev/null 2>&1)
Nov 4 08:58:24 dpit postfix/smtpd[12091]: connect from unknown[45.55.26.204]
Nov 4 08:58:28 dpit postfix/anvil[11810]: statistics: max connection rate 1/60s for (smtp:45.55.26.204) at Nov 4 08:54:59
Nov 4 08:58:28 dpit postfix/anvil[11810]: statistics: max connection count 1 for (smtp:45.55.26.204) at Nov 4 08:54:59
Nov 4 08:58:28 dpit postfix/anvil[11810]: statistics: max cache size 2 at Nov 4 08:55:07

Der daily.cron Ordner (von dem ich annehme, dass er die Probleme verursacht) sieht folgendermassen aus:

/etc/cron.daily # ls
50plesk-daily apache2 apt-compat aptitude bsdmainutils dpkg logrotate man-db mdadm passwd spamassassin sysstat webalizer

Wenn ich die letzten Commands vor den Crashes manuell laufen lasse, gibt es keinen Crash und ich kann also das Problem nicht reproduzieren.

Hat jemand eine Idee wie ich das angehen könnte?

Vielen Dank im Voraus

 

[Firewire2002]

Definiere Crash.

Stirbt nur ein Prozess?
IO Error?
Kernelpanic? (hier wäre die Meldung interessant)

 

[divepit]

Also die Website die drauf läuft kann nichtmehr aufgerufen werden und ich kann mich nicht mehr via ssh einloggen und muss den vserver via provider resetten..

Ich weiss nicht genau was stirbt.. Wo kann ich nach einem IO Error checken? Kernel panic glaub ich nicht, sieht im kern.log zumindest nicht danach aus. Da steht garnix um 6:25

 

[Firewire2002]

Hatte übersehen, dass es um einen vServer geht. IO Error würden auch alle anderen Kunden (mindestens auf dem gleichen Hostsystem) betreffen. Erstmal unwahrscheinlich, vorallem zur gleichen Zeit.

Was für eine Virtualisierungstechnik steckt drunter? Bei KVM oder VMware gäbe es die Möglichkeit den virtuellen "Monitor" anzuzeigen und damit auch die letzten Kernelmeldungen zu sehen, welche nicht mehr auf die Platte geschrieben werden konnten.
Bei Virtuozzo/OpenVZ wäre interessant, was von der Prozessliste noch übrig geblieben ist. Sofern noch UBC eingesetzt werden, wären auch die Fail Counter davon interessant.

Gibt es ein Monitoring der Ressourcenauslastung? Insbesondere vom RAM?
Wäre auch denkbar, dass ein anderer Prozess zu dem Zeitpunkt mehr Speicher benötigt als sonst und die Cronjobs der Auslöser für den OOM-Killer sind. Was sich dann regulär tagsüber nur schwer reproduzieren lässt.

 

[divepit]

Also eine KVM Konsole hab ich, dass kann ich morgen früh mal testen. Ich hab jetzt auch seitdem ich nen server health monitor drinn hab vermehrt warnungen zur Apache Memory Usage gekriegt.

Hab ein Bild von der RAM Statistik angehängt.

Denkst du also das es evtl. garkein fehlerhafter cronjob sondern einfach eine überlastung ist, die durch den cronjob einen peak erreicht?

 

[divepit]

Hab hier noch ein paar zusätzliche statistiken von apache und nginx angehängt.

 

[Thunderbyte]

Doppelpost zu https://forum.hetzner.com/thread/25489-täglicher-crash-um-6-25/ (nicht öffentliches Hetzner Kundenforum). Doppelposts sind zu vermeiden. Allerdings ist die Gruppe der möglichen Antwortenden im Hetzner Forum natürlich sehr viel kleiner. Entscheidet selbst, wie Ihr hier verfahren wollt.

Hinweis an den TE: Falls es im Hetzner Forum zur Lösung kommt, sind selbstverständlich die Helfer hier zu informieren.

Zum Thema: was passiert denn am Sa um 18:30 das den RAM Verbrauch schlagartig so hoch treibt?

Wird da ein lokales Backup irgendwohin geschrieben? Kann es evtl sein, das der Teil des Filesystems ("df") einfach volläuft?

 

[divepit]

Im Hetzner Post hat es auch jemand erwähnt, hab nicht gewusst, dass man das nicht so machen soll. Kommt nicht mehr vor.

Hab mal nachgeschaut und der command, welcher von Plesk um 18:37 ausgeführt wird sieht folgendermassen aus:

/opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/catalog/scripts/update-index.php'

und hat die beschreibung "Extension Catalog"
Ich hab am folgenden Tag noch sämtliche Mail Extensions (SMTP, IMAP, POP3, etc.) deinstalliert, da ich konstant via SMTP brutforced wurde und ich eigentlich keinen Mailserver drauf brauche. Seither ist der Server nicht mehr eingefroren.

Hab aber wirklich immernoch keinen Plan an was es gelegen hat.. Danke für die Tipps
​