[CentOS] Dovecot .99 Bug - LF not found where expected

[Scott Lamb]

Bazooka Joe wrote:
> upgrade to 1.0 - fixes several bugs
> 
> w/ .99 outlook will spontaneously redownload all the main in your
> mailbox thinking it is new.
> 
> that lf error was so bad on my server that I wrote a perl script to
> check for it and fix it ran w/ cron every min. (this was on a fc 4 box
> - should be same)
> 
> $w=`/usr/bin/tail -n 500 /var/log/maillog`;
> if ($w =~ /LF not found where expected/) {
>    $w=~/\/var\/mail\/(.*):/;
>    print $1;
>    $m=`/usr/bin/formail -ds </var/mail/$1 >>/var/mail/$1.rebuild`;
>    $t=`/bin/cp /var/mail/$1.rebuild /var/mail/$1`;
>    $r=`/bin/rm /var/mail/$1.rebuild`;
> }

Ergh. Some things to consider changing next time you write a script like
this.

1) you need a lockfile to prevent it from running more than once
simultaneously. (see the "lockfile" utility for a good way to do this
even from shell scripts.) this is particularly important when you're
launching a job every minute from cron. there are all sorts of reasons
the system can bog down for a minute, and two simultaneous copies of
this script would trip over each other badly.

I stick lockfiles under /var/lock, so if you lose power while your
script is running, /etc/rc.sysinit will delete the lock on next boot and
your script will pick up again. this choice means that your script
should work if there was a half-finished run before a full one, though,
see below.

2) it is appending to $1.rebuild rather than overwriting it, so if there
was a half-finished run before the file contents will be duplicated.
solve with > instead of >>.

3) if "formail" returns failure (say, out of some critical system
resource), you're probably going to lose whatever's in the file. check
the exit status and bail before the replacement to avoid this.

4) it's using "cp + rm" to replace the file. "mv" would be a lot better
- when src and dst are on the same filesystem, it atomically replaces
the destination (so no one will ever see a half-written file there), is
robust against running out of free disk inodes or blocks, and is even
faster. in your script, if the copy fails you'll delete both copies of
the file.

5) you can do stuff like copying and deleting and moving files directly
from Perl, which is faster and more robust than using `` and shell
utilities. eliminates failures like unable to fork(), etc.

-- 
Scott Lamb <http://www.slamb.org/>