fetchmail faalt door "too many open files"

[johu]

(Redhat 6.2 | fetchmail 5.5.0+IMAP-GSS+SSL )
Na een 'bepaalde' tijd stopt mijn fetchmail daemon ermee omdat er 'te veel open files zijn', ook kan de nameserver de pop3 host daarna niet meer resolven:

[fetchmail log]
...
fetchmail: 5.5.0 querying pop.wxs.nl (protocol POP3) at Fri, 22 Feb 2002 07:55:59 +0100 (CET)
fetchmail: 5.5.0 querying pop.wxs.nl (protocol POP3) at Fri, 22 Feb 2002 08:01:02 +0100 (CET)
fetchmail: fetchmail: POP3 connection to pop.wxs.nl failed: Too many open files
fetchmail: Query status=2 (SOCKET)
fetchmail: 5.5.0 querying pop.wxs.nl (protocol POP3) at Fri, 22 Feb 2002 08:06:03 +0100 (CET)
fetchmail: fetchmail: POP3 connection to pop.wxs.nl failed: temporary name server error.
fetchmail: Query status=2 (SOCKET)
fetchmail: 5.5.0 querying pop.wxs.nl (protocol POP3) at Fri, 22 Feb 2002 08:11:03 +0100 (CET)
fetchmail: fetchmail: POP3 connection to pop.wxs.nl failed: temporary name server error.
fetchmail: Query status=2 (SOCKET)
...

het vreemdste van alles vind ik het volgende:

de open files worden tijdens iedere 'fetchmail poll' apart opgeslagen in een logfile (m.b.v. lsof) -> gedeelte van zo'n logfile

als je het logfile bekijkt zie je dat fetchmail, lsof en lsof-logg (mijn post-fetchmail script) ontzettend veel 'open verbindingen ?!?' hebben met "->ns1.wxs.nl:domain" !!!

1). Wie weet waar dit aan ligt, en hoe ik het op kan lossen ?
2). Waarom blijven die verbindingen 'open' (ns1.wxs.nl) ???
3). Zijn er meer mensen die fetchmail als daemon gebruiken ? Hoelang houdt die daemon het vol ?

Ik ben echt al heel lang met dit probleem bezig !!! Op i-net staat alleen dat je het aantal open files in /proc/sys/fs/file-max moet verhogen ! dit heb ik nu al op 16000 staan !, dat is toch niet normaal ??? Want volgens mij moet de oplossing liggen bij die aantal 'open verbindingen' met ns1.wxs.nl !!!

[deadinspace]

Hmz, dat is een flinke lap connecties.
Ze zijn UDP, op naam van fetchmail vanaf jouw bak naar de domain poort van ns1.wxs.nl, dus het is duidelijk iets met DNS.

Net alsof fetchmail een DNS request doet naar ns1.wxs.nl en dan vindt dat hij niet snel genoeg antwoord krijgen en er dus nog maar eentje opent, en nog een en nog een

In die lsof-output van jou zijn het trouwens 833 connecties van fetchmail, 832 van lsof en 832 van 'lsof-logg'.. Wat is 'lsof-logg'? En ook een interessante vraag is: wrom opent lsof zelf zoveel connecties?

Als je fetchmail net gerestart hebt, heb je dan weinig connecties, en groeit het aantal connecties daarna gestaag? Of is het heel plotseling?

[johu]

lsof-logg is een script dat door fetchmail wordt uitgevoerd voordat ie een poll doet. Het is een pre-'connect command' en dit script wordt dan uitgevoerd. ( Ik weet dat het niet een net script is, maar ik ben ook maar een n00b en ik heb dit nooit ergens geleerd van school ofzo.;))

Het aantal connecties groeit gestaag, dat weet ik zeker. Dat valt ook te zien aan de vorige log-files. -> als ik fetchmail NET heb opgestart zijn d'r na een aantal poll's ook nog maar weinig connecties. Het lijkt d'r dus op dat de 'connecties' niet verbroken worden

En dat fetchmail connecties opent, daar kan ik nog wel inkomen, maar dat ook lsof en lsof-logg dat doen !!! Dat snap ik niet ! lsof is gewoon een progje dat de open processen laat zien op je systeem, en lsof-logg is een zelf gemaakt scriptje dat telkens de output van lsof in een nieuw logfiletje met als filename een timestamp.

(en wat is een UDP connectie ? is de enige andere een TCP ?)

[deadinspace]

Op zaterdag 11 mei 2002 09:08 schreef johu het volgende:
En dat fetchmail connecties opent, daar kan ik nog wel inkomen, maar dat ook lsof en lsof-logg dat doen !!! Dat snap ik niet ! lsof is gewoon een progje dat de open processen laat zien op je systeem, en lsof-logg is een zelf gemaakt scriptje dat telkens de output van lsof in een nieuw logfiletje met als filename een timestamp.

Dat lsof-logg het doet is niet zo gek; lsof-logg roept lsof aan, en lsof opent dus die connecties.

Dat lsof het doet... Mja, het lijken DNS requests. En lsof krijg van de kernel een lijst terug met open files, waarin connecties onder andere een IP hebben. Maar voor de gebruiker zijn hostnames meestal handiger, dus doet lsof een DNS request om het IP om te zetten naar een hostname.
Maar dat zou geen 800 keer moeten gebeuren, aangezien de libc6 DNS resolver dat afaik hoort te cachen (tis beetje onzin om voor 800 keer dezelfde hostname ook 800 DNS requests te doen).
Als IP in plaats van hostname je niet boeit bij lsofs output kun je 'lsof -n' doen, dan reverse-resolved lsof de IPs niet (scheelt ook in snelheid).

Maar waarom fetchmail zoveel connecties open? Geen idee...

(en wat is een UDP connectie ? is de enige andere een TCP ?)

TCP is de tegenhanger van UDP ja.
Beiden worden heel veel gebruikt over IP (en straks over IPv6): TCP/IP en UDP/IP.

TCP is hoge kwaliteit en connection based. Er moet eerst een connectie opgezet worden, en TCP probeert te garanderen dat alle verzonden data over die connectie ook daadwerkelijk aankomt, foutloos en in de juiste volgorde.
UDP is zo van 'ja, er is niet echt een connectie, maar stuur maar, dan komt het misschien aan. Zo niet, pech'.

DNS requests gaan doorgaans over UDP.