>>>>> "md" == Mark Delany <[EMAIL PROTECTED]> writes:
md> Whilst some inetd implementations have crude forms of DOS
md> protection (initially created for other reasons) I'm not aware of
md> too many that protect against concurrency - most do it by rate.
Heh. If I may take a slight detour to tell an inetd-related war
story, even if it isn't directly qmail-related....
In a former life, I was the sysadmin for a cable-based ISP in the US.
One customer was in the middle of transitioning email services from
machines they ran to our machines. Their boxes were using an older
Red Hat distribution and were using Sendmail + the Qualcomm POP
daemon. I avoided working on those machines (they weren't really
mine), but the transition wasn't going fast enough ... so I had to
grease the squeaky wheel.
In the evenings, the POP service would become unavailable due to
inetd's rate-limiting. Spending as little time as possible to "fix"
the problem, I had a cron job check the POP service every minute and
SIGHUP inetd every time it was unavailable. But during the busy
evening times, the SIGHUPs were remarkably frequent. Oh, 40-50
times/hour, with 5-minute load averages rising into the teens.
Trying another quick fix, I simply dropped qmail's tcpserver in place
of inetd for starting the POP server. I set the session limit at 60.
This killed the machine performance-wise. Thrash-O-Matic. Unlike
before, when the machine started thrashing now, it was pretty obvious
that syslog was a huge problem.
I finally discovered that syslogd was the cause. As syslog was
logging events from Sendmail and the POP daemon's login/logout events,
it used fsync() after each event. The disk couldn't keep up during
busy times, so openlog() calls started blocking ... causing load
averages to rise, delays in SMTP and POP server initial greetings, POP
client retries making things worse. Until the inetd throttle kicked
in. Then enough syslog could finally catch up, the number of blocked
processes dropped, and life returned to (near) normal. Then my cron
job would HUP inetd, and the cycle repeated. When I started using
tcpserver, things went to hell because there was no emergency escape
valve (namely that !@#$! inetd) to keep syslog from getting too busy.
I recompiled syslogd without the fsync() call, and the system gently
purred through the busiest times thereafter.
A lot of people don't know about inetd's throttle mechanism. I didn't
know there were any modern UNIXen which still used it. Live and
learn.
-Scott
---
Scott Lystig Fritchie
5401 - 10th Ave S, Minneapolis, MN 55417 USA
Professional Governing: Is It Faked?
