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.