Seit einem apt-get dist-upgrade auf einem meiner Debian-Server meldete die Überwachungslösung monit Probleme mit dem periodischen Check der Verfügbarkeit von HTTP-Servern:
... [CET Mar 1 19:28:18] error : 'printer.schloesslistrasse.local' failed protocol test [HTTP] at [10.1.2.3]:80/script/cookieCode.js [TCP/IP] -- HTTP: Error receiving data -- Resource temporarily unavailable ...
(Die URL hatte ich im Zuge des Debugging ergänzt, da ich zuerst nicht sicher war, ob monit eine allfällige HTTP 403er-Meldung sauer aufstossen würde — ohne aktiviertem Browser-JavaScript wird die Seite im wwwroot aber anstandslos ausgeliefert)
Ein zweiter Debian-Server hatte mit exakt denselben Checks keine Probleme. Der kleine, aber feine Unterschied: monit 5.9-1+deb8u1 (jessie, stable) zeigt das Fehlverhalten nicht, während 5.16-2 (sid, unstable) mit HTTP-Checks strauchelt. Doch das realisierte ich leider erst viel, viel später.
Zuerst machte ich mich im Quellcode der Anwendung schlau:
static void check_request(Socket_T socket, Port_T P) {
int status, content_length = -1;
char buf[512];
if (! Socket_readLine(socket, buf, sizeof(buf)))
THROW(IOException, "HTTP: Error receiving data -- %s", STRERROR);
Quelle: Monit / src / protocols / http.c
Das half dann doch weniger als erwartet zur Problemlösung bei.
Als nächste schraubte ich die Geschwätzigkeit der Installation hoch, indem ich in /etc/init.d/monit die Konfigurationsoption MONIT_OPTS anpasste:
... DAEMON=/usr/bin/monit CONFIG=/etc/monit/monitrc NAME=monit DESC="daemon monitor" #MONIT_OPTS= MONIT_OPTS="-vv" PID="/run/$NAME.pid" ...
Viel mehr gab das Log unter /var/log/monit dann aber doch nicht preis:
... [CET Mar 1 19:33:55] debug : Socket test failed for [10.1.2.3]:80 -- HTTP: Error receiving data -- Resource temporarily unavailable [CET Mar 1 19:33:55] error : 'printer.schloesslistrasse.local' failed protocol test [HTTP] at [10.1.2.3]:80/script/cookieCode.js [TCP/IP] -- HTTP: Error receiving data -- Resource temporarily unavailable [CET Mar 1 19:33:55] debug : ------------------------------------------------------------------------------- [CET Mar 1 19:33:55] debug : /usr/bin/monit() [0x8062c37] [CET Mar 1 19:33:55] debug : /usr/bin/monit(LogError+0x27) [0x8063097] [CET Mar 1 19:33:55] debug : /usr/bin/monit(Event_post+0x243) [0x805f573] [CET Mar 1 19:33:55] debug : /usr/bin/monit() [0x807373f] [CET Mar 1 19:33:55] debug : /usr/bin/monit(check_remote_host+0x16b) [0x8075bfb] [CET Mar 1 19:33:55] debug : /usr/bin/monit(validate+0x2e9) [0x8073e99] [CET Mar 1 19:33:55] debug : /usr/bin/monit(main+0x505) [0x8051d95] [CET Mar 1 19:33:55] debug : /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xde) [0xb728670e] [CET Mar 1 19:33:55] debug : /usr/bin/monit() [0x8052293] [CET Mar 1 19:33:55] debug : ------------------------------------------------------------------------------- ...
Nach viel Pröbeln hatte ich dann doch endlich die Erkenntnis, dass es wohl nicht die beste Idee war, ein als unstable markiertes Paket zu verwenden. Doch wie downgraden? Ganz einfach:
# apt-get install monit=1:5.9-1+deb8u1
Quelle: How to Downgrade a Package via apt-get?
Damit das Paket aber beim nächsten apt-get dist-upgrade nicht mit der fehlerhaften Version überschrieben wird, musste ich noch folgenden Befehl ausführen:
# apt-mark hold monit
Quelle: PinningHowto
Seither wird meine INBOX nicht mehr mit Warnungen geflutet.
