Thought I’d just post this since I didn’t find an authoritative answer on the web. Those using exim4 on a Debian testing or unstable system might recently have found their system broken after doing a dist-upgrade to version 4.67-7, with exim4-config failing to configure with a message similar to the following:

Exim configuration error in line 28 of /var/lib/exim4/config.autogenerated.tmp: malformed macro definition.

This is caused by the installer being unable to handle customised sections of your config files as it attempts to migrate them to the new version. In my case it was a bunch of configuration to support mailman that was causing the trouble. All I did was copy my entire /etc/exim4/ directory to another system, remove all exim4 packages (and --purge), reinstall exim4 and restore the relevant parts of my config (if you’re using mailman, use this guide). Mail service restored in about 2 minutes.

For those yet to do the upgrade to 4.67-7, copy your config files (/etc/exim4/) somewhere else, do a dist-upgrade, and accept the changes to your files the installer recommends. I haven’t done this so I don’t know if it will succeed in adapting your customised settings, but it should stop the package breaking. If necessary you can restore your settings from the backup you just took.

You may also wish to take a copy of your /etc/aliases file, though I found this wasn’t touched by apt when uninstalling exim4, even with the --purge option.

I’ve been having a lot of problems recently with my home Debian server locking up, with Apache processes swelling up until all RAM is eaten up and CPU 100% utilised. The box stops responding until I can get local access and restart Apache. This used to happen several times a week, despite actual load on the server being very low with hardly any web requests.

I put this down to the age of the install and some dodgy Apache settings and didn’t look too much into fixing it; I turned the child process settings down a lot which didn’t improve things, so I just set a cron job up to restart apache every so often. It was only when I came to install Debian on a brand-new server at work that I realised something was afoot - the Apache/PHP install on this new server was doing the same thing - locking up several times a day for no apparent reason and in the exact same way. Both servers would suddenly experience massive CPU and RAM utilisation; additionally Apache would take several minutes to get from startup to actually accepting requests, with huge CPU use in that time. Incidentally, my home box is testing/unstable and this new server is Etch (stable).

I spent a few minutes going through the config files for Apache, PHP and MySQL (also installed on my home box) in an effort to optimise the install, and examined the extensions list in php.ini to see if there were any I could remove. I unfortunately suffer from over-enthusiasm when installing things like PHP, XMMS and so on, whereby I read the list of related packages and install everything that I might possibly need someday or that could be useful at some point. In this case this included php4-clamavlib, which I installed thinking it might be good to play with on a rainy day.

A quick apt-get remove php4-clamavlib and I restarted Apache; to my surprise it came up in about two seconds as opposed to the three minutes it was taking before to stop using 100% CPU after being started. I watched the box carefully for the rest of the day and it had no problems. Upon getting home I did the same thing on my own server and it too appears to be cured. So if you’re having problems with Apache suddenly choking, check to see if you’ve got the ClamAV library for PHP installed. If you don’t need it, lose it!