All good points!
I was just going to post the actual formail fix for the jacked mailbox
but then posted my whole script. I just used it until I got 1.0
installed/configured/tested.
On 6/7/07, Scott Lamb <slamb at slamb.org> wrote:
> 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/>
> _______________________________________________
> CentOS mailing list
>CentOS at centos.org>http://lists.centos.org/mailman/listinfo/centos>