Hi, According to chapter 19 one should manually ensure that serialize-* files are nuked during system bootup if using the serialize_hosts option (which is a good thing on bandwidth constricted connections). Adding the following three lines to the top of the start() function in the start script achieves this, and I can't see it doing any actual harm. ebegin "Removing old serialization files (exim)" /usr/bin/find /var/spool/exim/db -name "serialize-*" -exec rm {} \; eend $? There are other ways of doing this too. Either way, I see this as an enhancement, not a serious problem. It's IMHO probably a good thing to rather clean up these files during exim startup rather than in local.start (as exim would actually already be operating at that time). Reproducible: Always Steps to Reproduce:
This needs a little more work, ideally it should query the exim binary and config options to determine if seralize_hosts is in use, if so, it should then purge the spool directory (which may or may not be /var/spool/exim/db), I'll have a think on this a bit and see if/when it will make it into the tree.
Reassign to net-mail herd as peitolm retires
Drawback of cleaning them upon exim start is that you can't easily restart exim without cleaning the files (if you don't want that). It should only be done at (re)boot. It almost feels like those files should be placed in /tmp instead, such that they are cleaned if the system was configured as such.
Fabian, Why not? When restarting exim the delivery instances will be stopped too as far as I understand, so there should not be any problems with nuking those files. I've had cases where exim died, leaving behind these serialization files resulting in a system that was unable to delivery outbound email to a couple of servers. Can anybody please indicate exactly what I'd need to get done on this additionally to get it merged?
why would putting the serialisation files in /tmp not work for you?
Hi Guys, Would just like to bump this. Just for clarity, the manual states: "Because Exim operates in a distributed manner, if several messages for the same host arrive at around the same time, more than one simultaneous connection to the remote host can occur. This is not usually a problem except when there is a slow link between the hosts. In that situation it may be helpful to restrict Exim to one connection at a time. This can be done by setting serialize_hosts to match the relevant hosts. "Exim implements serialization by means of a hints database in which a record is written whenever a process connects to one of the restricted hosts. The record is deleted when the connection is completed. Obviously there is scope for records to get left lying around if there is a system or program crash. To guard against this, Exim ignores any records that are more than six hours old. "If you set up this kind of serialization, you should also arrange to delete the relevant hints database whenever your system reboots. The names of the files start with misc and they are kept in the spool/db directory. There may be one or two files, depending on the type of DBM in use. The same files are used for ETRN serialization." The second paragraph in particular applies. Both a program (exim) or system crash can trigger this. The 6 hour delay is a workable solution but it does cause needless delays. We still see this quite often, most of the time it's caused by system crashes (usually power cuts). http://www.exim.org/exim-html-current/doc/html/spec_html/ch-exim_utilities.html#SECThindatmai Is hinting at the fact that exim_tinydb can also be used to clean up that file. Please note that previous information applied to exim 3 and not exim 4, thus the find mechanism is outdated. My suggestion would be to simply add this as pre-start: exim_tinydb /var/spool/exim/ misc The whole process doesn't even take a second, so honestly there really isn't much reason to not do this.
Just to be clear here: you suggest we add a call to exim_tidydb in the init-script for start/restart for all databases Is this right? I think this makes sense judging from the documentation. It's up to the sys/mailadmin to run the tool when exim runs, but removing stale entries when Exim is (re)started will not impact anything, so a safe and sensical option.
I was actually only considering misc to clean up the serialization stuff, but as you state there is no harm in cleaning all. So yes - for all databases would be good. Based on my systems (and someone will have to verify that this is indeed generic/good enough) I've got a bunch of .lockfile files for the databases, and since I also store a number of .dbm files in there for autoresponder rate limiting my suggested solution would then be: clean_dbs() { local dbf for dbf in /var/spool/exim/db/*.lockfile; do /usr/sbin/exim_tidydb /var/spool/exim "$(basename "${dbf}" .lockfile)" done } And then arrange for clean_dbs to be called prior to actually starting exim. This does output to the terminal, eg: Tidying Exim hints database /var/spool/exim/db/callout deleted ... (too old) ... Tidying complete Tidying Exim hints database /var/spool/exim/db/misc Tidying complete Tidying Exim hints database /var/spool/exim/db/retry Tidying complete Tidying Exim hints database /var/spool/exim/db/wait-remote_smtp updated somename:17 Tidying complete This may not be acceptable, so if not, just do for example: einfo "Cleaning DBs" clean_dbs &>/dev/null eend $? I normally like knowing what's going on, but again, I'd only really like to know if cleanups was made and the output is completely useless for the most part.
right, this was the approach I was taking here :)
I've committed this to 4.85, please let me know if this does what you need. Thanks!
