Falscher Serverstatus?

[tuxi66]

Nach stundenlanger und schlafloser Nacht, langen suchen, testen, Ausschlussverfahren, wende ich mich an euch mit dem Problem in ISPConfig. Wir betreiben 2 Webserver (gleiche Serverkonfiguration und ISPConfig Version). Deshalb haben wir einen direkten Vergleich, den wir intensiv nutzen.

Bei einem Webserver erhalten wir in der Serverstatus Anzeige (ISPConfig 3.1.14p2) seit gestern den Fehler: "Einer oder mehrere benötigte Dienste sind offline" - laut Dienststatus sei IMAP Server und MySQL Server OFFLINE. (nach einem herben Angriff auf IMAP; monit hat in kurzer Zeit mehrfach dovecot, amavisd, MySQL, apache und postfix neu gestartet; wir haben darauf hin die entsprechenden Netzwerke der "Störenfriede" via iptables voll gesperrt; alle Dienste liefen laut monit und Systemcheck wieder normal, ausser Serverstausmeldung in ISPConfig wie im Bild gezeigt)

In Monit wird alles als online angezeigt und auch auf dem Server selbst scheint alles gut zu laufen. Webseiten sind erreichbar, Mailverkehr funktioniert, MySQL ist local (von localhost) und via Browser erreichbar, ...

Wir haben den Server mehrmals neugestartet. Vieles, was ähnlich wie unser Fehler hier im Forum gepostet wurde, nachvollzogen und viele Tests durchgeführt. Sämtliche log-files "durchforstet" und versucht den Fehler zu finden.

Unsere Tests ohne das der Fehler behoben werden konnte:
- localhost kann auf MySQL und Dovecot zugreifen:

mysql -h localhost -u root = ich war in mysql

root@meinserver ~ # nc -zv localhost 3306
Connection to localhost 3306 port [tcp/mysql] succeeded!

root@meinserver ~ # nc -zv localhost 143
Connection to localhost 143 port [tcp/imap2] succeeded!

root@meinserver ~ # nc -zv localhost 993
Connection to localhost 993 port [tcp/imaps] succeeded!

• sämtliche Konfigurationen wurden unter beiden Server verglichen und keine Unterschiede festgestellt
• ispconfig update durchgeführt und in /usr/local/ispconfig/server/temp/ befindet sich keine .ispconfig_cron_lock
• resync aus ISPConfig durchgeführt
• services gestoppt und neugestartet
• die Diagnose-Datei htf-common-issues.php ausgeführt und den daraus gewonnen Report auf Fehler untersucht (Report im Anhang: htf_report.txt)

##### SERVER #####
IP-address (as per hostname): ***.***.***.***
IP-address(es) (as per ifconfig): ***.***.***.***
[INFO] ISPConfig is installed.

##### ISPCONFIG #####
ISPConfig version is 3.1.14p2


##### VERSION CHECK #####

[INFO] php (cli) version is 7.3.7-2+ubuntu16.04.1+deb.sury.org+1

##### PORT CHECK #####


##### MAIL SERVER CHECK #####


##### RUNNING SERVER PROCESSES #####

[INFO] I found the following web server(s):
    Apache 2 (PID 3021)
[INFO] I found the following mail server(s):
    Postfix (PID 10314)
[INFO] I found the following pop3 server(s):
    Dovecot (PID 7805)
[INFO] I found the following imap server(s):
    Dovecot (PID 7805)
[INFO] I found the following ftp server(s):
    PureFTP (PID 10430)

##### LISTENING PORTS #####
Server)        ()
Local        (Address)
[anywhere]:110        (7805/dovecot)
[anywhere]:143        (7805/dovecot)
[anywhere]:465        (10314/master)
***.***.***.***:53        (10444/named)
[localhost]:53        (10444/named)
[anywhere]:21        (10430/pure-ftpd)
[anywhere]:22        (1466/sshd)
[localhost]:953        (10444/named)
[anywhere]:25        (10314/master)
[anywhere]:2812        (27600/monit)
[anywhere]:993        (7805/dovecot)
[anywhere]:995        (7805/dovecot)
[localhost]:10023        (881/postgrey.pid)
[localhost]:10024        (10055/amavisd-new)
[localhost]:10025        (10314/master)
[localhost]:10026        (10055/amavisd-new)
[localhost]:10027        (10314/master)
[anywhere]:587        (10314/master)
[localhost]:11211        (1385/memcached)
[localhost]10        (7805/dovecot)
[localhost]43        (7805/dovecot)
*:*:*:*::*:8080        (3021/apache2)
*:*:*:*::*:80        (3021/apache2)
*:*:*:*::*:8081        (3021/apache2)
*:*:*:*::*:465        (10314/master)
*:*:*:*::*:53        (10444/named)
*:*:*:*::*:21        (10430/pure-ftpd)
*:*:*:*::*:4949        (880/perl)
*:*:*:*::*:22        (1466/sshd)
*:*:*:*::*:953        (10444/named)
*:*:*:*::*:25        (10314/master)
*:*:*:*::*:443        (3021/apache2)
*:*:*:*::*:2812        (27600/monit)
*:*:*:*::*:993        (7805/dovecot)
*:*:*:*::*:995        (7805/dovecot)
*:*:*:*::*:10024        (10055/amavisd-new)
*:*:*:*::*:3306        (947/mysqld)
*:*:*:*::*:10026        (10055/amavisd-new)
*:*:*:*::*:587        (10314/master)

##### IPTABLES #####

... sehr viele Zeilen, darum entfernt.

In der iptables ist weder localhost noch localhost.localdomain, 127.0.0.1, ::1, ip6-localhost, ip6-loopback, Server-IPv4, Server-IPv6 gesperrt.

Es scheint das ISPConfig eine Fehlinformation hat und diese nicht mehr "verliert".
Es wäre super, wenn wir hier bei euch Hilfe bekommen.
Beste Grüße Doris und Steffen

 

[Till]

Im Grunde ist das was Du getestet hast auch das, was ispconfig macht:

/* Monitor IMAP-Server */
        $data['imapserver'] = -1; // unknown - not needed
        if ($services['mail_server'] == 1) {
            if ($this->_checkTcp('localhost', 143)) {
                $data['imapserver'] = 1;
            } else {
                $data['imapserver'] = 0;
                $state = 'error'; // because service is down
            }
        }

/* Monitor MySQL Server */
        $data['mysqlserver'] = -1; // unknown - not needed
        if ($services['db_server'] == 1) {
            if ($this->_checkTcp('localhost', 3306)) {
                $data['mysqlserver'] = 1;
            } else {
                $data['mysqlserver'] = 0;
                $state = 'error'; // because service is down
            }
        }

Die -CheckTCP methode versucht im Grunde nur ein fsockopen aufd en Port und wenn der funktioniert, gibt es true zurück

$fp = @fsockopen($host, $port, $errno, $errstr, 2);

 

[tuxi66]

Danke für deine Antwort.
Den von dir angegebenen code konnten wir in der Datei
/usr/local/ispconfig/server/lib/classes/monitor_tools.inc.php sehen und nachvollziehen. Um zu testen ob die php-Anweisung auf unserem Server richtig funktioniert, haben wir mal "fix" eine php-Testdatei erstellt, um via ssh auf der Konsole die Funktion zu prüfen. Hinweis: Wir sind keine Programmierer, deshalb ist die Datei sehr simpel geschrieben und sicherlich programmiertechnisch nicht einwandfrei.

test.php

#!/usr/bin/php -q
<?php

$host = 'tcp://localhost';
$port = '80';

$fp = @fsockopen($host, $port, $errno, $errstr, 2);
if (!$fp) {
  echo "$port: $errstr ($errno)\n";
} else {
  echo "$port: funktioniert\n";
}
fclose($fp);


$host = 'tcp://localhost';
$port = '21';

$fp = @fsockopen($host, $port, $errno, $errstr, 2);
if (!$fp) {
  echo "$port: $errstr ($errno)\n";
} else {
  echo "$port: funktioniert\n";
}
fclose($fp);


$host = 'tcp://localhost';
$port = '25';

$fp = @fsockopen($host, $port, $errno, $errstr, 2);
if (!$fp) {
  echo "$port: $errstr ($errno)\n";
} else {
  echo "$port: funktioniert\n";
}
fclose($fp);


$host = 'tcp://localhost';
$port = '110';

$fp = @fsockopen($host, $port, $errno, $errstr, 2);
if (!$fp) {
  echo "$port: $errstr ($errno)\n";
} else {
  echo "$port: funktioniert\n";
}
fclose($fp);


$host = 'tcp://localhost';
$port = '143';

$fp = @fsockopen($host, $port, $errno, $errstr, 2);
if (!$fp) {
  echo "$port: $errstr ($errno)\n";
} else {
  echo "$port: funktioniert\n";
}
fclose($fp);


$host = 'tcp://localhost';
$port = '53';

$fp = @fsockopen($host, $port, $errno, $errstr, 2);
if (!$fp) {
  echo "$port: $errstr ($errno)\n";
} else {
  echo "$port: funktioniert\n";
}
fclose($fp);


$host = 'tcp://localhost';
$port = '3306';

$fp = @fsockopen($host, $port, $errno, $errstr, 2);
if (!$fp) {
  echo "$port: $errstr ($errno)\n";
} else {
  echo "$port: funktioniert\n";
}
fclose($fp);


$host = 'udp://localhost';
$port = '123';

$fp = @fsockopen($host, $port, $errno, $errstr, 2);
if (!$fp) {
  echo "$port: $errstr ($errno)\n";
} else {
  echo "$port: funktioniert\n";
}
fclose($fp);

exit;
?>

Auf der Konsole haben wir die Datei test.php aufgerufen und folgendes Ergebnis wurde angezeigt:

root@meinserver /tmp # php -q test.php
80: funktioniert
21: funktioniert
25: funktioniert
110: funktioniert
143: funktioniert
53: funktioniert
3306: funktioniert
123: funktioniert

Wir schliessen daraus, dass die Abfragen (php-Funktion innerhalb ISPConfig) der Services korrekt funktionieren. Doch die Ergebnisse werden nicht mehr in die grafische ISPConfig Ansicht (Serverstatus Anzeige und Dienststatus siehe Bild im 1. Beitrag) übernommen.

Folglich liegt der Fehler zwischen Funktionsausführung und Ergebnisanzeige?
Und das wiederum sind Abläufe innerhalb ISPConfig.
Es wäre super, wenn wir diesen "Schönheitsfehler" bereinigen könnten.

Noch ein Hinweis: wir möchten an der Stellen noch einmal darauf hinweisen, dass beschriebener Fehler nach einem herben Angriff auf IMAP mit Folge ständiger Neustarts diverser Services (siehe Text 1. Beitrag) durch monit übrig geblieben ist. Könnte dadurch eventuell eine Fehlinformation in den ISPConfig Kreislauf geraten sein?

 

[Till]

Möglicherweise wird der Status garnicht mehr aktualisiert. Kommt ein fehler wenn Du folgendes als root aufrufst?

/usr/local/ispconfig/server/cron.sh

ggf. vorher mal log level auf debug setzen in System > server config

 

[tuxi66]

Nein, es kommt absolut keine Meldung. Auch nach Aktivierung des log level auf debug nicht. Es steht auch nichts in der syslog. Es scheint, als tut es gar nichts. Das bedeutet der Aufruf /usr/local/ispconfig/server/cron.sh ist wirkungslos?

Wir haben uns die cron.sh etwas genauer angesehen und festgestellt das die dort angegeben Datei php.ini gar nicht existiert.

#!/bin/bash

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin

if [ -f /usr/local/ispconfig/server/lib/php.ini ]; then
        PHPINIOWNER=`stat -c %U /usr/local/ispconfig/server/lib/php.ini`
        if [ $PHPINIOWNER == 'root' ] || [ $PHPINIOWNER == 'ispconfig' ]; then
                export PHPRC=/usr/local/ispconfig/server/lib
        fi
fi

cd /usr/local/ispconfig/server
/usr/bin/php -q \
    -d disable_classes= \
    -d disable_functions= \
    -d open_basedir= \
    /usr/local/ispconfig/server/cron.php
/usr/local/ispconfig/server/cron.sh (END)

Aufruf: less /usr/local/ispconfig/server/lib/php.ini
Antwort: /usr/local/ispconfig/server/lib/php.ini: Datei oder Verzeichnis nicht gefunden

Demnach sollten wie die Datei wieder herstellen? Könnte vielleicht noch mehr fehlen? Können wir die Datei aus einer Sicherung wieder herstellen?

Update 05.08.2019 19:45 Uhr
Ich habe gerade das mit unserem anderen Webserver verglichen, in dem alles richtig funktioniert. Dort sieht die cron.php genauso aus und die dort angegeben Datei php.ini existiert dort auch nicht.

 

[Till]

Es scheint, als tut es gar nichts. Das bedeutet der Aufruf /usr/local/ispconfig/server/cron.sh ist wirkungslos?

Nein, wenn kein Fehler komnmt dann läuft es.

Wir haben uns die cron.sh etwas genauer angesehen und festgestellt das die dort angegeben Datei php.ini gar nicht existiert.

Das ist ok, die ist optional und normalerweise nicht vorhanden.

Demnach sollten wie die Datei wieder herstellen? Könnte vielleicht noch mehr fehlen? Können wir die Datei aus einer Sicherung wieder herstellen?

nein

Schau mal bitte mit 'crontab -e' ob der cronjob der cron.sh started nicht auskommentiert ist.

 

[tuxi66]

Ich habe nachgeschaut. So sehen die Einträge aus:

* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
* * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done

 

[Till]

das ist ok.

 

[tuxi66]

Wenn der Systemdatenbestand soweit bzw. scheinbar in Ordnung ist, aber die Serverstatus-Information 2 falsche Meldungen zeigt, stellen sich folgende Fragen:

• Nimmt die Statusabfrage mit ihrem Ergebnis ihren Weg zur Statusanzeige über die ISPConfig Datenbank?
• Folglich könnte entweder eine falsche oder defekte Information die Funktionalität der Datenbank behindern?
• Wenn ja, ist die entsprechende Stelle reparabel? Oder gar die gesamte Datenbank?
• Andererseits könnte uns zur Reparatur eine Sicherung der Datenbank vom 24.07.2019 weiterhelfen (Sicherung vor dem Update von Version 3.1.14p1 auf 3.1.14p2)?
• Oder liegen wir am Ende mit unserer Vermutung eines möglichen Datenbankfehlers total falsch?

Nachtrag:
Wir konnten in der ISPConfig Datenbanktabelle 'monitor_data' unter Typ 'services' folgende Einträge finden:

Spalte	Wert
server_id	1
type	services
created	1564761604
data	a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:0;s:10:"bindserver";i:1;s:11:"mysqlserver";i:0;}
state	error

1564761604 ergibt das Datum: 02.08.2019 mit der dazugehörigen Zeit: 18:00:04

Daraus entnehmen wir, dass der Serverstatus seit 02.08.2019 18:00:04 nicht mehr erneuert wird.
Inzwischen haben wir zusätzlich auf der Textkonsole mit:

mysqlcheck --tables dbispconfig --analyze

und

mysqlcheck --tables dbispconfig --check

die Datenbank geprüft. Es ist alles in Ordnung.

Demnach müssen wir für eine Lösung des Problems dafür sorgen, dass der Serverstaus wieder aktualisiert wird?

Nachtrag 2:
Durch die eben erstellte Tabelle erinnerten wir uns an die Datei:
/usr/local/ispconfig/server/temp/rescue_module_monitoringdata.ser.txt. (Zeitstempel = 06.08.2019 18:30)
Uns ist aufgefallen, dass diese Datei immer aktualisiert wird. Aktuell steht darin:

a:11:{i:0;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:1;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:2;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:3;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:4;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:5;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:6;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:7;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:8;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:9;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}i:10;a:1:{i:0;a:4:{s:9:"server_id";i:1;s:4:"type";s:8:"services";s:4:"data";a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}s:5:"state";s:2:"ok";}}}

Könnte ganau das unser Fehler sein?

 

[Till]

Die informationen werden über die Datenbank ausgetauscht, und nicht über diese Datei. Tabelle ist glaube ich monitor_data, wenn ich mich recht entsinne.

 

[tuxi66]

Genau, die Tabelle ist monitor_data und wir haben dessen Inhalt in obiger Tabelle eingebracht. Unter Spalte data steht:

a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:0;s:10:"bindserver";i:1;s:11:"mysqlserver";i:0;}

und der Zeitstempel ist: 1564761604 -> 02.08.2019 18:00:04

Das heißt, die Datenbanktabelle wird seit 02.08.2019 18:00:04 nicht mehr aktualisiert, aber genannte Datei mit aktuellen Zeitstempel und teilweise gleichem Inhalt (Auszug):

a:7:{s:9:"webserver";i:1;s:9:"ftpserver";i:1;s:10:"smtpserver";i:1;s:10:"pop3server";i:1;s:10:"imapserver";i:1;s:10:"bindserver";i:1;s:11:"mysqlserver";i:1;}

Wenn wir nun vergleichen, stellen wir den Unterschied zwischen Datenbank und Datei wie folgt fest:
alles gleich außer:

• s:11:"mysqlserver";i:0; in Datebanktabelle mit Datum 02.08.2019
• s:11:"mysqlserver";i:1; in genannter Textdatei mit aktuellem Datum

sowie

• s:10:"imapserver";i:0; in Datebanktabelle mit Datum 02.08.2019
• s:10:"imapserver";i:1; in genannter Textdatei mit aktuellem Datum

Frage: woher, wenn nicht aus genannter Textdatei, bezieht die Datenbanktabelle ihre Inhalte bzw. Werte?

 

[Till]

Frage: woher, wenn nicht aus genannter Textdatei, bezieht die Datenbanktabelle ihre Inhalte bzw. Werte?

Da sind wir wieder bei dem cron.sh script das wir bereits oben hatten. cron.sh ruft cron.php auf und cron.php ruft zu den jeweils konfigurierten Zeitpunkten die cron plugins in /usr/local/ispconfig/server/lib/classes/cron.d/ auf und da findet Ihr auch die monitor services welche den Status in die Datenbank schreibt.

Ihr könnt mal in die sys_cron datebanktabelle schauen was dort steht wann cronjob_monitor_services das letzte mal lief und wann es das nächste mal laufen soll. Ihr könnt auch das cron_debug.php script verwenden um das cron plugin manuell zu starten.

Die Datei von der Du sprichst hat mit dem rscue system zu tun und nicht mit dem Monitor. Rescue system ist separat, sie System > server config > Rescue

 

[tuxi66]

Danke für den wichtigen Hinweis.
In der Datebanktabelle sys_cron unter cronjob_monitor_services lesen wir:
last_run 2019-08-02 18:05:02
next_run 2019-08-02 18:10:00
runnig 1
Daraus entnehmen wir, dass das System immer noch der Meinung ist, der letzte Cron läuft noch was uns running 1 sagt.

Frage: Wenn wir in der Datenbanktabelle running auf 0 stellen und next_run auf einen noch kommenden Zeitpunkt, müsste der Fehler behoben sein? Wenn du das genauso siehst, werden wir mutig sein und wie beschrieben vorgehen. Wenn das bei uns hilft, dann hilft es auch bei anderen.

 

[Till]

Löscht einfach den ganzen eintrag für den job.

 

[tuxi66]

Vielen Dank. Jetzt ist alles wieder im grünen Bereich!

Wir hatten nicht den Mut, den ganzen Eintrag zu löschen. Wir wissen Datenbanken reagieren manchmal sehr empfindlich auf Veränderungen die direkt in den Tabellen erfolgen. Es gibt viele Tabellen die miteinander verknüpft sind. Also haben wir den Eintrag, wie von uns oben beschrieben, angepasst. In der Datenbanktabelle sys_cron haben wir uns an den Zeiten der anderen cronjob Einträge orientiert. Siehe Bild:

Danach war die Serverstatus Anzeige und die Dienststatus Anzeige in ISPConfig wieder OK.

Für uns ist es wichtig auch die Ursache für solche plötzlich auftretenden Fehler zu wissen. Da der Fehler unmittelbar im Zusammenhang des herben Angriffs auf IMAP (wie bereits oben im 1. Beitrag beschrieben) mit Folge ständiger Neustarts diverser Dienste stand (dabei wurde auch die Datenbank immer wieder neu gestartet - das sagt der Zeitstempel), wird mit hoher Wahrscheinlichkeit der cron den Eintrag in der Datenbank nicht vollständig beendet haben und ist deshalb unvollendet "stecken geblieben".

Wir haben 2 Webserver mit Ubuntu und ISPConfig seit über 1 Jahr laufen und sind sehr zufrieden. Das Vertrauen in die Software ISPConfig ist mit diesem Vorfall sehr gestiegen. Wir danken Till für seine Hilfe mit uns den Fehler einzugrenzen und schlussendlich zu beseitigen.

Ergänzung: Zusätzlich haben wir auf beiden Webservern den Hinweis aus dem Tutorial von Till "The Perfect Server - Debian 10 (Buster) with Apache, BIND, Dovecot, PureFTPD and ISPConfig 3.1"
aufgegriffen und die Erhöhung der Limits für MariaDB angepasst. (in der Doku zu finden unter: 8 Install Postfix, Dovecot, MariaDB, rkhunter, and Binutils)

 

[Till]

Für uns ist es wichtig auch die Ursache für solche plötzlich auftretenden Fehler zu wissen. Da der Fehler unmittelbar im Zusammenhang des herben Angriffs auf IMAP (wie bereits oben im 1. Beitrag beschrieben) mit Folge ständiger Neustarts diverser Dienste stand (dabei wurde auch die Datenbank immer wieder neu gestartet - das sagt der Zeitstempel), wird mit hoher Wahrscheinlichkeit der cron den Eintrag in der Datenbank nicht vollständig beendet haben und ist deshalb unvollendet "stecken geblieben".

Ja, das wüde ch auch denken.

Generell ist es so dass man die Tabelle sys_cron auch komplett leeren kann im Notfall, sie ist direkt nach der Installation auch leer. Das zwingt alle cronjobs zu einem ersten neuen Lauf. Nur als Hinweis.