SolarCatcher
Well-Known Member
Hallo,
ich werde nicht schlau daraus: Seit einigen Wochen sehe ich fast täglich in den /var/log/messages eines Servers Meldungen wie diese
Jetzt könnte ich natürlich einfach die Anzahl der erlaubten Verbindungen hochsetzen. Aber eigentlich will ich ja schon wissen, welcher Dienst in welcher Jail hier die Ursache ist. Ich bin daher nach dem in einem Blog-Post beschriebenen Weg vorgegangen und habe anhand der PCB ID versucht, den Verursacher mit "netstat -aAn" zu identifizieren. Leider stets ohne Erfolg.
Ich dachte zunächst, dass es daran läge, dass die verursachende Prozess möglicherweise schon wieder eine andere PCB ID hat (was ich mittlerweile für unwahrscheinlich halte, weil die ID in der o.g. Kernel message oft über Stunden oder sogar mehr als einen Tag konstant bleiben). Ich habe sogar einen Cron angelegt, der minütlich netstat nach der letzten in /var/log/messages genannten PCB ID durchsucht und in einem Logfile abspeichert (kann man vermutlich einfacher machen... aber viele Wege führen nach Rom):
Hat jemand eine andere Idee, wie ich herausfinde, wer/wo/was die Ursache für die Listen Queue Overflow ist?
Nur der Vollständigekeit halber: Das System ist ein HardenedBSD 11-STABLE - sollte sich also ansich wie ein 11er FreeBSD verhalten. Zumindest für den Weg der Fehleranalyse.
ich werde nicht schlau daraus: Seit einigen Wochen sehe ich fast täglich in den /var/log/messages eines Servers Meldungen wie diese
Code:
Mar 29 00:12:44 meinserver kernel: [1582194] sonewconn: pcb 0xfffff804803f63a0: Listen queue overflow: 76 already in queue awaiting acceptance (3 occurrences)
Jetzt könnte ich natürlich einfach die Anzahl der erlaubten Verbindungen hochsetzen. Aber eigentlich will ich ja schon wissen, welcher Dienst in welcher Jail hier die Ursache ist. Ich bin daher nach dem in einem Blog-Post beschriebenen Weg vorgegangen und habe anhand der PCB ID versucht, den Verursacher mit "netstat -aAn" zu identifizieren. Leider stets ohne Erfolg.
Ich dachte zunächst, dass es daran läge, dass die verursachende Prozess möglicherweise schon wieder eine andere PCB ID hat (was ich mittlerweile für unwahrscheinlich halte, weil die ID in der o.g. Kernel message oft über Stunden oder sogar mehr als einen Tag konstant bleiben). Ich habe sogar einen Cron angelegt, der minütlich netstat nach der letzten in /var/log/messages genannten PCB ID durchsucht und in einem Logfile abspeichert (kann man vermutlich einfacher machen... aber viele Wege führen nach Rom):
Code:
netstat -aAn | grep `grep 'Listen queue overflow' /var/log/messages | tail -n1 | grep -o '0xffff[^\:]*' | grep -o 'ffff[^\:]*'` >> /var/log/listenQueueOverflow.log
Hat jemand eine andere Idee, wie ich herausfinde, wer/wo/was die Ursache für die Listen Queue Overflow ist?
Nur der Vollständigekeit halber: Das System ist ein HardenedBSD 11-STABLE - sollte sich also ansich wie ein 11er FreeBSD verhalten. Zumindest für den Weg der Fehleranalyse.