Pre-queue content-filter connection overload

In the last while I've been seeing the following error pop up in my logwatch report for postfix:


*Warning: Pre-queue content-filter connection overload


At first I was concerned that the pre-queue content-filtering subsystem of postfix was somehow being overwhelmed and I was possibly loosing mail. Digging around a bit more lead to these types of log entries that seemed like they were the subject of the logwatch report:


Feb 21 13:01:45 pyxidis postfix/smtpd[5994]: connect from unknown[unknown]
Feb 21 13:01:45 pyxidis postfix/smtpd[5994]: lost connection after CONNECT from unknown[unknown]
Feb 21 13:01:45 pyxidis postfix/smtpd[5994]: disconnect from unknown[unknown]


Huh?!
From what I can glean here the log entries above indicate that a SMTP connection was established with the kernel but the connecting host hot potatoed it before postfix was able to process the connection.

When postfix tries to process the connection there's nobody home because the kernel had already removed the connection and it dumps something like the lines above to the mail log.

Wherefor?
Here's the scoop from the logwatch docs:


This sometimes occurs in reaction to a portscan or broken bots, or when postfix is overloaded, due to excessive header_checks / body_checks content filtering, or even too few smtpd processes to service the demand. One could reduce the number of header_checks and body_checks, and possibly set smtpd_timeout to 60 (seconds). The key is that existing clients are overloading the number of smtpd daemons. The postfix-logwatch section configuration variable is postfix_ConnectionLostOverload, and the command line option is --connectionlostoverload. If you consider this sub-section to be meaningless, set the level limiter value to 0 and the sub-section will be suppressed.


I was not going to change my header or body checks (because they keep the unwashed spammers at bay) so I opted for tuning my smtpd_timeout down to 30 seconds in main.cf.

Because this looks like it is a possible resource issue you could also up the amount of smtpd processes allowed to service the pre-queue content-filtering subsystem.

Firefox 3 (beta x) and Firebug

18 February 2008

Firefox 3 (beta x) and Firebug

My favourite extension, by far, for Firefox is Firebug. It is a combination of strace and tcpdump for web applications. It allows you to drill down into all aspects of the send-response loop between your browser and a web app.

If you're doing any JavaScript/AJAX development this tool will be invaluable to you!

Living on the edge though, as you do, I upgraded the version of Firefox I was running to v3.0b3 and too my annoyance Firebug now no longer worked.

Damn.

Lucky for me the crew at Fireclipse have enhanced Firebug 1.05 by Joe Hewitt with enhancements and bug fixes. I simply grabbed the XPI from here and installed it from within Firefox.

Et Voilà!

Another Reality Dysfunction is averted and life continues unimpeded.

Dovecot time Machine

05 January 2008

Dovecot time Machine

I have a XEN virtual machine which was complaining about time. Dovecot seemed to be the most vocal with errors like this in the logs:


dovecot: IMAP(charl): Time just moved backwards by 1 seconds. I'll sleep now until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards


I run openntpd (OpenBSD NTP daemon) on the box but that was not seemingly keeping the date, well, up-to-date. Manually running ntpdate was also not providing the sync I sought and because this is a XEN box I have no access to hwclock.

Travelling back in time
A bit of digging on my provider's forums though showed that they were controlling the time syncing and had forgotten to turn the time sync back on after some troubleshooting they were doing.

That's all good and well but my box was still not syncing.

The Dovecot linked article in the log error message simply states:


With Xen you should run ntpd only in dom0. Other domains should synchronize time automatically (see this Xen FAQ).


XEN wisdom
The XEN FAQ has the following relevant things to say about time on a XEN box:


Q: My xen machines doesn't accept setting its time. Basically, it's stuck to RTC time. ntpdate, date, hwclock all "seem" to work, but they don't actually change the system time. The only way I have to change it right now is to change it in the BIOS.
A: Only affects 1.0. Fixed in newer versions.

Q: Where does a domain get its time from?
A: Briefly, Xen reads the RTC at start of day and by default will track that with the precision of the periodic timer crystal. Xen's estimate of the wall-clock time can only be updated by domain 0. If domain 0 runs ntpdate, ntpd, etc. then the synchronised time will automatically be pushed down to Xen every minute (and written to the RTC every 11 minutes, just as normal x86 Linux does). All other domains always track Xen's wall-clock time: setting the date, or running ntpd, on these domains will not affect their wall-clock time. Note that the wall-clock time exported by Xen is UTC --- all domains must have appropriate timezone handling (i.e. a correct /etc/localtime file).

Q: Is there is some cross-domain time synchronization : are they always in perfect sync, or should I run some kind of ntp in each subdomain ? Or only domain 0 would be enough ?
A:If you want each domain to keep its own time, there are two ways to cause a domain to run its wallclock independently from Xen:
1. Specify 'independent_wallclock' on the command line.
2. 'echo 1 >/proc/sys/xen/independent_wallclock'

To reenable tracking of Xen wallclock:
1. 'echo 0 >/proc/sys/xen/independent_wallclock'


"Shut it down, Shut it down forever!"
Following the FAQ I modified /proc/sys/xen/independent_wallclock and added it to /etc/sysctl.conf ("xen.independent_wallclock = 1") so that the change would survive a reboot.

I also changed my timezone to the same local as where I am working currently by doing the following:

$ sudo cp /usr/share/zoneinfo/Australia/Sydney /etc/localtime

Time marches on
openntpd now keeps time synced and Dovecot no longer complains about running in the future.