Likes: 
Ola,
first post maar wel gelijk een lastig probleem:
Op m'n colocated server (linux, debian, sarge) draait al jaren sendmail. Sinds 3 dagen doet sendmail (en bind 9.2.4) raar, al dan niet dankzij een upgrade.
Spam wordt geblokkeerd via de blacklisting van sbl-xml.spamhaus.org
sendmail.mc:
FEATURE(`dnsbl', `sbl-xbl.spamhaus.org', `', `"451 Temporary lookup failure for " $&{client_addr} " in sbl-xbl.spamhaus.org"')
Wat ik sinds merk is dat sommige inkomende spam-connecties blijven hangen. Met als gevolg dat er een child-process van sendmail blijft hangen en na verloop van tijd komt het aantal processen aan het ingestelde maximum en gaat sendmail inkomende mail weigeren. Da' s niet handig.
Verder doet bind/named (9.2.4-1sarge1) raar. Die knalt er soms opeens uit, soms al na enkele uren. Na ook jaren trouw dienst gedaan te hebben. Geen melding in de logfile met log severity info. level debug is niet prettig ; te groot log en vertraagt server.
Op de server draaien een tiental beperkt bezochte domeinen die amper 500+ emails in totaal per dag ontvangen (en soms versturen via een mailscript). Verder worden dankzij de dnsbl een kleine 2500 spamberichten per dag eruit gefilterd. Er draait geen content-scanner zoals clamav.
De server is een oud beestje met ondertussen een vrij antieke kernel (2.4.26) die in principe vanaf remote veilig moet zijn. Er zijn wel lokale exploits mogelijk maar klanten e.d. kunnen in principe niet op de bak en alle klanten zijn close c.q. persoonlijk bekend. Een fikse update is wel wenselijk maar elke keer als ik in Amsterdam ben heb ik wat anders aan m'n hoofd dan de kernel te upgraden (bv disk fixen of voeding vervangen etc zoals afgelopen dinsdag/Redbus-festijn)
Nu net is het aantal sendmail-children al op z'n max gekomen. Een quote:
root 31069 0.0 0.3 6944 2712 ? Ss 22:54 0:01 sendmail: MTA: rejecting connections on daemon MTA13: 40 children, max 40
root 31826 0.0 0.4 7264 3232 ? S 23:21 0:00 sendmail: MTA: server pool-71-252-4-50.washdc.east.verizon.net [71.252.4.50] cmd read
root 31833 0.0 0.3 6956 2768 ? S 23:21 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31834 0.0 0.3 6956 2768 ? S 23:21 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31837 0.0 0.3 6956 2768 ? S 23:21 0:00 sendmail: MTA: startup with tre.koolkookies.com
root 31843 0.0 0.3 6956 2768 ? S 23:22 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31844 0.0 0.3 6956 2768 ? S 23:22 0:00 sendmail: MTA: startup with [222.222.184.144]
root 31845 0.0 0.3 6956 2768 ? S 23:22 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31851 0.0 0.3 6956 2768 ? S 23:23 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31852 0.0 0.3 6956 2768 ? S 23:23 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31874 0.0 0.3 6956 2768 ? S 23:24 0:00 sendmail: MTA: startup with pool-70-18-22-37.ny325.east.verizon.net
root 31875 0.0 0.3 6956 2768 ? S 23:24 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31877 0.0 0.3 6956 2768 ? S 23:24 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31918 0.0 0.3 6956 2768 ? S 23:25 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31919 0.0 0.3 6956 2768 ? S 23:25 0:00 sendmail: MTA: startup with pool-71-252-4-50.washdc.east.verizon.net
root 31940 0.0 0.3 6956 2768 ? S 23:27 0:00 sendmail: MTA: startup with 24-107-161-230.dhcp.nwnn.ga.charter.com
root 31941 0.0 0.3 6956 2768 ? S 23:27 0:00 sendmail: MTA: startup with chello080108083038.32.11.vie.surfer.at
root 31944 0.0 0.3 6956 2768 ? S 23:28 0:00 sendmail: MTA: startup with 24-107-161-230.dhcp.nwnn.ga.charter.com
root 31950 0.0 0.3 6956 2768 ? S 23:28 0:00 sendmail: MTA: startup with tre.koolkookies.com
root 31951 0.0 0.3 6956 2768 ? S 23:28 0:00 sendmail: MTA: startup with 24-107-161-230.dhcp.nwnn.ga.charter.com
root 31952 0.0 0.3 6956 2768 ? S 23:28 0:00 sendmail: MTA: startup with [218.75.113.146]
de lijst gaat nog verder door. Het is alsof sendmail z'n spammende connecties niet (goed) wil afsluiten en dan z'n children niet opschoont.
De enige manier om hier vanaf te komen is door sendmail hard te killen met een kill -9 ; een gewone /etc/init.d/sendmail stop of restart werkt niet. De losse mta's zijn wel af te sluiten maar de 1e (max 40 bereikt) gaat alleen weg met een kill -9.
Heeft iemand suggesties ?
