mailserver werkt opeens nietmeer

[a casema user]

Mijn mailserver Communicate Pro (v 4.0.5) crasht nu elke keer na ongeveer een half uur terwijl het altijd goed gewerkt heeft.
Hieronde uit de logs de foutmeldingen.

15:25:05.09 0 SYSTEM server 4.0.2 started under Linux, open files limit=1024
15:25:05.09 0 SYSTEM process core dump limit=976M
15:30:15.45 0 SYSTEM server 4.0.2 stopped under Linux
16:59:04.97 0 SYSTEM server 4.0.2 started under Linux, open files limit=1024
16:59:04.97 0 SYSTEM process core dump limit=976M
17:04:15.49 0 SYSTEM server 4.0.2 stopped under Linux
17:05:53.33 0 SYSTEM server 4.0.2 started under Linux, open files limit=1024
17:05:53.33 0 SYSTEM process core dump limit=976M
17:11:03.40 0 SYSTEM server 4.0.2 stopped under Linux
17:11:26.64 0 SYSTEM server 4.0.2 started under Linux, open files limit=1024
17:11:26.64 0 SYSTEM process core dump limit=976M
17:16:36.51 0 SYSTEM server 4.0.2 stopped under Linux
17:19:33.08 0 SYSTEM server 4.0.5 started under Linux, open files limit=1024
17:19:33.08 0 SYSTEM process core dump limit=976M
17:24:43.47 0 SYSTEM server 4.0.5 stopped under Linux
17:29:01.90 0 SYSTEM server 4.0.5 started under Linux, open files limit=1024
17:29:01.90 0 SYSTEM process core dump limit=976M

ligt het aan de mailserver of aan de server (RH 7.x , kernel 2.4.19)
Ik heb de mailserver al geupdate naar de nieuwste versie maar dat helpt dus ook niet.

Graag wat hulp om dit op te lossen.

--edit--
ik heb dmv up2date een aantal packets geupdate, zou het daar aan kunnen liggen ?

[Sat Feb 1 03:07:15 2003] up2date installing packages: ['krb5-devel-1.2.2-16', 'krb5-libs-1.2.2-16']
[Sat Feb 1 03:07:24 2003] up2date Removing packages from package profile: ['krb5-devel-1.2.2-15', 'krb5-libs-1.2.2-15']
[Sat Feb 1 03:07:25 2003] up2date Adding packages to package profile: ['krb5-devel-1.2.2-16', 'krb5-libs-1.2.2-16']

[ Voor 14% gewijzigd door a casema user op 01-02-2003 17:45 ]

[Verwijderd]

genoeg hdd ruimte over? (df -h) en kijk is hoe de progs met hun geheugen omgaan (top)

[a casema user]

ik heb nog ruim 2,5 Gb over dus dat lijkt me genoeg.
En qua geheugen ziet alles er ook redelijk normaal uit, ik heb al verschillende programma;s opnieuw opgestart om wat meer geheugen te krijgen.

[jant]

Hier is iets goed mis. Het ziet er naar uit dat je kist tegen het maximale aantal open files aanloopt.

Betreft het hier een veelgebruikte machine of gewoon voor thuisgebruik ?

Je kunt je je max-files at run-time verhogen met het volgende commando:
# echo 2048 > /proc/sys/fs/file-max

Bovenstaand commando verdubbelt het max aantal open files.

Beter lijkt het me als je de oorzaak van de max open file oorzaak vind!

[ Voor 42% gewijzigd door jant op 01-02-2003 20:32 . Reden: Toevoeging verhogen max open files ]

[a casema user]

Ik gebruik het alleen voor thuis en de mailserver heeft maar 3 accounts.
Er staat wel redelijk veel in (65 Mb in 1 account) maar dat mag toch geen enkel probleem zijn ?

[Kees]

hmmjah
# echo 4096 > /proc/sys/fs/file-max is een gevolg bestrijding (wel goed btw)

Ik zou eerder kijken naar wat er allemaal openstaat met lsof, maybe dat je een process kan spotten dat idioot veel open files heeft..

[Kees]

Was toch al met scripten bezig, hiermee kun je zien hoeveel files elk process open heeft:

Bash:

#!/bin/bash
pids=`/usr/bin/lsof | tr -s ' ' | cut -d ' ' -f1 | uniq | tr "\n" ' '`
for i in ${pids}; do
    count=`/usr/bin/lsof | grep "^${i}" | wc -l`
    echo "${i}: $count"
done

om het iets makkelijker te maken

[a casema user]

#lsof | grep CGServer | wc -l
1224

met lsof komt er inderdaad veel CGServer voor, een selectie ervan (de rest was ongeveer hetzelfde)

CGServer 28625 root 3r FIFO 0,5 3464680 pipe
CGServer 28625 root 4w FIFO 0,5 3464680 pipe
CGServer 28625 root 5u unix 0xc6b7b100 3464681 socket
CGServer 28625 root 6r REG 3,1 6 340037 /var/CommuniGate/ProcessID
CGServer 28625 root 7u REG 3,1 346884 340462 /var/CommuniGate/SystemLogs/2003-02-01.log
CGServer 28625 root 8u IPv4 3464684 UDP *:3390
CGServer 28625 root 9r REG 3,1 255 243129 /var/CommuniGate/Directory/Main.data
CGServer 28625 root 10u REG 3,1 0 243128 /var/CommuniGate/Directory/Main.updates
CGServer 28625 root 11u REG 3,1 0 291742 /var/CommuniGate/Queue/680001.tmp
CGServer 28625 root 12u REG 3,1 0 291754 /var/CommuniGate/Queue/680002.tmp
CGServer 28625 root 13u REG 3,1 0 291778 /var/CommuniGate/Queue/680003.tmp
CGServer 28625 root 14u REG 3,1 0 292057 /var/CommuniGate/Queue/680004.tmp
CGServer 28625 root 15u REG 3,1 0 292187 /var/CommuniGate/Queue/680005.tmp
CGServer 28625 root 16u IPv4 3464694 TCP *:8025 (LISTEN)
CGServer 28625 root 17u IPv4 3464696 TCP *:8674 (LISTEN)
CGServer 28625 root 18u IPv4 3464699 TCP *:8106 (LISTEN)
CGServer 28625 root 19u IPv4 3464701 TCP *:8993 (LISTEN)
CGServer 28625 root 20u IPv4 3464703 TCP *:8143 (LISTEN)
CGServer 28625 root 21u IPv4 3464705 TCP *:8110 (LISTEN)
CGServer 28625 root 22u IPv4 3464707 TCP *:jetdirect (LISTEN)
CGServer 28625 root 23u IPv4 3464709 TCP *:8100 (LISTEN)
CGServer 28625 root 24u IPv4 3464711 TCP *:9010 (LISTEN)
CGServer 28625 root 25u IPv4 3464713 TCP *:8010 (LISTEN)
CGServer 28625 root 26u IPv4 3464715 TCP *:8636 (LISTEN)
CGServer 28625 root 27u IPv4 3464717 TCP *:8389 (LISTEN)
CGServer 28625 root 28u IPv4 3464719 TCP *:8021 (LISTEN)
CGServer 28626 root cwd DIR 3,1 4096 340773 /var/CommuniGate
CGServer 28626 root rtd DIR 3,1 4096 2 /
CGServer 28626 root txt REG 3,1 3840212 809700 /opt/CommuniGate/CGServer
CGServer 28626 root mem REG 3,1 494486 130095 /lib/ld-2.2.4.so
CGServer 28626 root mem REG 3,1 531552 242950 /lib/i686/libpthread-0.9.so
CGServer 28626 root mem REG 3,1 85171 129959 /lib/libcrypt-2.2.4.so
CGServer 28626 root mem REG 3,1 5792553 242944 /lib/i686/libc-2.2.4.so
CGServer 28626 root 0u CHR 1,3 179747 /dev/null
CGServer 28626 root 1u CHR 1,3 179747 /dev/null
CGServer 28626 root 2u CHR 1,3 179747 /dev/null
CGServer 28626 root 3r FIFO 0,5 3464680 pipe
CGServer 28626 root 4w FIFO 0,5 3464680 pipe

[_JGC_]

jant schreef op 01 February 2003 @ 20:28:
Hier is iets goed mis. Het ziet er naar uit dat je kist tegen het maximale aantal open files aanloopt.

Betreft het hier een veelgebruikte machine of gewoon voor thuisgebruik ?

Je kunt je je max-files at run-time verhogen met het volgende commando:
# echo 2048 > /proc/sys/fs/file-max

Bovenstaand commando verdubbelt het max aantal open files.

Beter lijkt het me als je de oorzaak van de max open file oorzaak vind!

Denk niet dat je daar veel aan zult hebben. Alles boven de 1024 is zinloos, 1024 is nml de limiet hardcoded in pthread, onderdeel van glibc. Kan je trouwens wel aanpassen in de source, pthread opnieuw compilen en je hebt die limiet van 1024 niet meer
Ideaal voor apache webservers die hele dagen uit hun neus staan te vreten maar liefst wel iets meer dan 1024 connecties willen kunnen maken.

[Fatal-Error]

15:25:05.09 0 SYSTEM server 4.0.2 started under Linux, open files limit=1024
15:25:05.09 0 SYSTEM process core dump limit=976M

Deze twee regels zijn geen fouten, maar gewoon meldingen bij het starten van de server.
Ook zit er steeds 10 minuten tussen starten en stoppen van de server. Lijkt dus op een soort time-out... probeert de mailserver in die periode iets te versturen?
De periode tussen stoppen en starten is vrij onregelmatig; herstart je de server steeds zelf of gebeurt dat door een script?

[a casema user]

Fatal-Error schreef op 02 February 2003 @ 13:00:
[...]

Deze twee regels zijn geen fouten, maar gewoon meldingen bij het starten van de server.
Ook zit er steeds 10 minuten tussen starten en stoppen van de server. Lijkt dus op een soort time-out... probeert de mailserver in die periode iets te versturen?
De periode tussen stoppen en starten is vrij onregelmatig; herstart je de server steeds zelf of gebeurt dat door een script?

Voor zover ik weet wordt er helemaal niets verstuurd in die tussentijd en staat niets in de queue.
Tussen stoppen en starten is onregelmatig omdat ik het zelf handmatig opnieuw opstart.

idee om de server een keer te laten rebooten of zal dat niets uitmaken ? (wel zonde van mijn 104 dagen uptime)

[deadinspace]

_JGC_ schreef op 01 February 2003 @ 23:40:
Denk niet dat je daar veel aan zult hebben. Alles boven de 1024 is zinloos, 1024 is nml de limiet hardcoded in pthread, onderdeel van glibc. Kan je trouwens wel aanpassen in de source, pthread opnieuw compilen en je hebt die limiet van 1024 niet meer
Ideaal voor apache webservers die hele dagen uit hun neus staan te vreten maar liefst wel iets meer dan 1024 connecties willen kunnen maken.

Heb jij het niet toevallig over het aantal processes (...dat gespawned kan worden dmv pthread), in plaats van het aantal open files?

[Fatal-Error]

a casema user schreef op 01 February 2003 @ 17:42:
ik heb dmv up2date een aantal packets geupdate, zou het daar aan kunnen liggen ?

Probeer eens om die oude packages weer terug te zetten. Misschien dat je mailserver er na 5 minuten pas achterkomt dat ie bepaalde libs mist... of dat ie niet de goede heeft.

[a casema user]

Fatal-Error schreef op 02 February 2003 @ 20:48:
[...]

Probeer eens om die oude packages weer terug te zetten. Misschien dat je mailserver er na 5 minuten pas achterkomt dat ie bepaalde libs mist... of dat ie niet de goede heeft.

maar na de update van die packets heb ik ook de gehele mailserver geupdate dus lijkt me sterk dat hij dan bepaalde lib. mist....

[_JGC_]

deadinspace schreef op 02 February 2003 @ 15:57:
[...]

Heb jij het niet toevallig over het aantal processes (...dat gespawned kan worden dmv pthread), in plaats van het aantal open files?

elke fork() opent een filehandle

[jant]

_JGC_ schreef op 01 februari 2003 @ 23:40:
[...]


Denk niet dat je daar veel aan zult hebben. Alles boven de 1024 is zinloos, 1024 is nml de limiet hardcoded in pthread, onderdeel van glibc. Kan je trouwens wel aanpassen in de source, pthread opnieuw compilen en je hebt die limiet van 1024 niet meer
Ideaal voor apache webservers die hele dagen uit hun neus staan te vreten maar liefst wel iets meer dan 1024 connecties willen kunnen maken.

Ik ben hier benieuwd naar. Neen, ik ben geen kernel hacker of zo, maar problemen met max open file worden nagenoeg altijd opgelost door de limiet te verhogen van de betreffende parameter.

Feitelijk zeg je dat het geen zin heeft, maar ja probleempjes verdwijnen wel.

Ben nu benieuwd wat je precies bedoeld.

[Verwijderd]

jant schreef op 02 February 2003 @ 22:08:
[...]

Ik ben hier benieuwd naar. Neen, ik ben geen kernel hacker of zo, maar problemen met max open file worden nagenoeg altijd opgelost door de limiet te verhogen van de betreffende parameter.

Feitelijk zeg je dat het geen zin heeft, maar ja probleempjes verdwijnen wel.

Ben nu benieuwd wat je precies bedoeld.

Het klopt dat het aantal maximale open processen hard-coded in g-lib zit.
Of dat iets te maken heeft met het maximale aantal open files weet ik niet zeker.
Als het klopt dat elke fork() een file-handle dan zou dat dus inderdaad invloed moeten hebben.

[a casema user]

eeuh, dit gaat een beetje offtopic.
De computer is voor thuisgebruik en het lijkt me sterk dat mijn mailserver zoveel bestanden/processen open heeft staat dat de mailserver crasht.
Reboot een optie ?

[jant]

a casema user schreef op 03 February 2003 @ 06:54:
eeuh, dit gaat een beetje offtopic.
De computer is voor thuisgebruik en het lijkt me sterk dat mijn mailserver zoveel bestanden/processen open heeft staat dat de mailserver crasht.
Reboot een optie ?

Ik vind het niet echt off topic. Ik noem het uitdiscusieren.

Denk dat een reboot louter sympthoon bestrijding is.

[Verwijderd]

jant schreef op 03 February 2003 @ 07:19:
[...]

Ik vind het niet echt off topic. Ik noem het uitdiscusieren.

Denk dat een reboot louter sympthoon bestrijding is.

Gelieve dit niet nogmaals te doen als topicstarter duidelijk (en terecht) aangeeft dat het wel erg offtopic gaat.

[jant]

Verwijderd schreef op 02 februari 2003 @ 22:22:
[...]


Het klopt dat het aantal maximale open processen hard-coded in g-lib zit.
Of dat iets te maken heeft met het maximale aantal open files weet ik niet zeker.
Als het klopt dat elke fork() een file-handle dan zou dat dus inderdaad invloed moeten hebben.

IK heb nog eens wat (enigszins vluchtig) naslag werk gedaan. Maar volgens mij is het zo dat in de oudere 2.2 kernels maximaal 1024 files per proces aankunnen.

[jant]

Verwijderd schreef op 03 februari 2003 @ 07:22:

[...]


Gelieve dit niet nogmaals te doen als topicstarter duidelijk (en terecht) aangeeft dat het wel erg offtopic gaat.

U meent dit serieus? Wonderlijk.

Zijn meldingen zijn duidelijk. Probleempje in de richting van te veel open files. Daar is enige discussie over geweest en zou kunnen bijdragen aan een oplossing.

Ik zal het verder laten zitten:)

[ Voor 4% gewijzigd door jant op 03-02-2003 07:46 ]

[Verwijderd]

offtopic:
Hoe kom je er bij dat het probleem duidelijk is?

Die open files limit is namelijk puur en alleen een verbose melding bij het opstarten van ComminiGate Pro (van het maximale aantal open files).

Daarnaast had je reply natuurlijk niks te maken met hetgeen je nu aanhaalt
Maar goed, zo raken we alleen nog maar verder offtopic

[jant]

a casema user schreef op 01 February 2003 @ 21:57:
#lsof | grep CGServer | wc -l
1224

!< 1024

[Verwijderd]

Excuses, daar heb ik overheen gelezen.
Maar dat neemt de opmerking nog niet weg en inmiddels kan ik die ook naar mezelf gaan maken, want we zijn al weer 6 replies verder die volledig offtopic zijn

[a casema user]

Om het weer ontopic te krijgen.
Het probleem is opgelost.
Ik had een tikfout gemaakt met mijn serialnummer en dat checkt die dus schijnbaar opeens en gooide me er dus eruit.
Maar het werkt nu dus weer

[Verwijderd]

Wel een bugje dan als je het mij vraagt