After about three years of this, it seems I have finally gotten somewhere near to the bottom of this.
The symptom:
Suddenly a user cannot download their email. Checking again through SquirrelMail, I get an error which says a log was written.
Going to the logs I see
"imap(username): Error indexing mbox file /var/mail/username: LF not found where expected"
Using Webmin's read mail module, I can see the messages. So, I move them to another account, but this is not yet the end of it. I was at first having to delete the mbox and then I'd send a test message in to recreate the mbox. But today, I tried a different tack.
I opened the now empty mbox in vi and found one blank line (LF). I deleted that line and then moved the mail back in and everything was fixed. So the line was still left behind.
The next time this happens, I'm going to try to delete a LF from the top of the mbox file to see if it is fixed without moving the mail.
I have read several places, although this is extremely difficult to track as there seems to be a multiple from address issue for some releases.. but anyway, I did finally find that dovecot .99 has an issue with leaving behind an extra linefeed at the beginning of the mbox. Deleting this linefeed fixes the problem. Supposedly dovecot 1 has fixed this problem.
I have found many reports of problems on Fedora and RedHat. Also, Debian has a closed bug report regarding this issue as they have moved forward to dovecot-1.0 and it doesn't have this bug. The issue seems to not have any relation to the mailserver, as I saw both reports of problems on at least Sendmail and Postfix.
Why are we still bugged with this? Seems that this is a bug that RedHat should be aware of?
The problem is it only rarely happens. I have no idea how to repeat the issue. It always seems to be an Outlook user, although that is by far the most prevalent email client in use by our users and it might just be chance.
So, what to do from here? Bug report to RedHat? This is most irritating! I can't even guess how many times I've fixed these mboxes. I'm about ready to toss dovecot in the trash until 1 becomes the RH standard unless there is a fix or upgrade from Redhat.
Thanks, John Hinton
John Hinton wrote:
After about three years of this, it seems I have finally gotten somewhere near to the bottom of this.
The symptom:
Suddenly a user cannot download their email. Checking again through SquirrelMail, I get an error which says a log was written.
Going to the logs I see
"imap(username): Error indexing mbox file /var/mail/username: LF not found where expected"
Using Webmin's read mail module, I can see the messages. So, I move them to another account, but this is not yet the end of it. I was at first having to delete the mbox and then I'd send a test message in to recreate the mbox. But today, I tried a different tack.
I opened the now empty mbox in vi and found one blank line (LF). I deleted that line and then moved the mail back in and everything was fixed. So the line was still left behind.
The next time this happens, I'm going to try to delete a LF from the top of the mbox file to see if it is fixed without moving the mail.
I have read several places, although this is extremely difficult to track as there seems to be a multiple from address issue for some releases.. but anyway, I did finally find that dovecot .99 has an issue with leaving behind an extra linefeed at the beginning of the mbox. Deleting this linefeed fixes the problem. Supposedly dovecot 1 has fixed this problem.
I have found many reports of problems on Fedora and RedHat. Also, Debian has a closed bug report regarding this issue as they have moved forward to dovecot-1.0 and it doesn't have this bug. The issue seems to not have any relation to the mailserver, as I saw both reports of problems on at least Sendmail and Postfix.
Why are we still bugged with this? Seems that this is a bug that RedHat should be aware of?
The problem is it only rarely happens. I have no idea how to repeat the issue. It always seems to be an Outlook user, although that is by far the most prevalent email client in use by our users and it might just be chance.
So, what to do from here? Bug report to RedHat? This is most irritating! I can't even guess how many times I've fixed these mboxes. I'm about ready to toss dovecot in the trash until 1 becomes the RH standard unless there is a fix or upgrade from Redhat.
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
Scott Silva wrote:
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Best,
Chris Mauritz wrote:
Scott Silva wrote:
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Best,
I have filed bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243168
If any of you want to follow/participate.
John Hinton
John Hinton spake the following on 6/7/2007 10:30 AM:
Chris Mauritz wrote:
Scott Silva wrote:
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Best,
I have filed bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243168
If any of you want to follow/participate.
John Hinton
I don't think RedHat will upgrade to 1.0 since the config file format is different. But stranger things have happened.
Scott Silva wrote:
John Hinton spake the following on 6/7/2007 10:30 AM:
Chris Mauritz wrote:
Scott Silva wrote:
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Best,
I have filed bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243168
If any of you want to follow/participate.
John Hinton
I don't think RedHat will upgrade to 1.0 since the config file format is different. But stranger things have happened.
I sort of expected that might be the case.. but they've made backported repairs many times in the past. Maybe we'll get lucky? Otherwise, I guess I'll either ride it out until all the systems are on version 5, throw in the towel and dump dovecot, or go outside of the standard packaging and do what you did. At least I'll see on my version 5 systems any time when dovecot is patched and know to go look for a patch to my other systems.
I feel better about having some banter on this issue. I spent hours trying to figure out what was happening, have spent hours dealing with email issues and found very little in my googling to figure out what exactly was happening. I've only had one worse 'search' experience. If you ever have an issue with 'My Computer' in windoze, especially if it's doing something that might be common, like locking up... try searching on that one!!! ;) The SquirrelMail generated log was actually the saving factor, pointing me to the LF issue.
Thanks, John Hinton
John Hinton spake the following on 6/7/2007 10:59 AM:
Scott Silva wrote:
John Hinton spake the following on 6/7/2007 10:30 AM:
Chris Mauritz wrote:
Scott Silva wrote:
> Thanks, > John Hinton > Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Best,
I have filed bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243168
If any of you want to follow/participate.
John Hinton
I don't think RedHat will upgrade to 1.0 since the config file format is different. But stranger things have happened.
I sort of expected that might be the case.. but they've made backported repairs many times in the past. Maybe we'll get lucky? Otherwise, I guess I'll either ride it out until all the systems are on version 5, throw in the towel and dump dovecot, or go outside of the standard packaging and do what you did. At least I'll see on my version 5 systems any time when dovecot is patched and know to go look for a patch to my other systems.
I feel better about having some banter on this issue. I spent hours trying to figure out what was happening, have spent hours dealing with email issues and found very little in my googling to figure out what exactly was happening. I've only had one worse 'search' experience. If you ever have an issue with 'My Computer' in windoze, especially if it's doing something that might be common, like locking up... try searching on that one!!! ;) The SquirrelMail generated log was actually the saving factor, pointing me to the LF issue.
Thanks, John Hinton
The 1.0.0 upgrade was almost painless, but your pop3 users that leave mail on the server will download again. Otherwise it works better with outlook and outlook express, and the indexes are more robust on imap. 0.99 was almost unusable with outlook and imap.
On 08/06/2007, at 3:07 AM, Scott Silva wrote:
John Hinton spake the following on 6/7/2007 10:30 AM:
Chris Mauritz wrote:
Scott Silva wrote:
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Best,
I have filed bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243168
If any of you want to follow/participate.
John Hinton
I don't think RedHat will upgrade to 1.0 since the config file format is different. But stranger things have happened.
How much different? does it pose much of an issue if one does decide to upgrade.
I'm considering the update to 1.0.0 from rpmforge too?
anyone had any issues with this so far?
Cheers,
Michael
Michael Kratz spake the following on 6/7/2007 4:49 PM:
On 08/06/2007, at 3:07 AM, Scott Silva wrote:
John Hinton spake the following on 6/7/2007 10:30 AM:
Chris Mauritz wrote:
Scott Silva wrote:
> Thanks, > John Hinton > Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Best,
I have filed bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243168
If any of you want to follow/participate.
John Hinton
I don't think RedHat will upgrade to 1.0 since the config file format is different. But stranger things have happened.
How much different? does it pose much of an issue if one does decide to upgrade.
I'm considering the update to 1.0.0 from rpmforge too?
anyone had any issues with this so far?
The only 2 "issues" I had was pop3 users that leave mail on the server will download it all again, and imap users might see their folders refresh a time or two. The defaults in the rpmforge repo config are similar to the defaults in 0.99 on CentOS. Just add the appropriate client workarounds for outlook and outlook express.
On Thursday 07 June 2007 17:59, Chris Mauritz wrote:
Scott Silva wrote:
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Best,
Could you please give the URL for the download. I'm looking at rpmforge site and all I can see is 0.99-14
I know it's a friday but...
Tony
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Tony Molloy wrote:
On Thursday 07 June 2007 17:59, Chris Mauritz wrote:
Scott Silva wrote:
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Could you please give the URL for the download. I'm looking at rpmforge site and all I can see is 0.99-14
I know it's a friday but...
I am pretty sure I used this:
http://atrpms.net/dist/fc6/dovecot/
Sorry, it wasn't rpmforge after all.
Best,
On Friday 08 June 2007 12:07, Chris Mauritz wrote:
Tony Molloy wrote:
On Thursday 07 June 2007 17:59, Chris Mauritz wrote:
Scott Silva wrote:
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Could you please give the URL for the download. I'm looking at rpmforge site and all I can see is 0.99-14
I know it's a friday but...
I am pretty sure I used this:
http://atrpms.net/dist/fc6/dovecot/
Sorry, it wasn't rpmforge after all.
Best,
Happens to the best of us at times. I just thought I was going blind ;-)
Thanks,
Tony
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Tony Molloy wrote:
On Friday 08 June 2007 12:07, Chris Mauritz wrote:
Tony Molloy wrote:
On Thursday 07 June 2007 17:59, Chris Mauritz wrote:
Scott Silva wrote:
A RedHat bug report is your only option if you stay with 0.99. I bit the bullet and upgraded to 1.0.0 with an rpm from rpmforge. The performance is much better. Almost as much improvement as when I first switched from wuimap.
I agree with Scott. I also bit the bullet and went to 1.0 (also from rpmforge) and am testing it now. It is noticeably faster and I look forward to not dealing with that bug again (though it doesn't happen very often).
Could you please give the URL for the download. I'm looking at rpmforge site and all I can see is 0.99-14
I know it's a friday but...
I am pretty sure I used this:
http://atrpms.net/dist/fc6/dovecot/
Sorry, it wasn't rpmforge after all.
Best,
Happens to the best of us at times. I just thought I was going blind ;-)
Thanks,
Tony
Boy, this is starting to sound like it might be a really good package to add to CentOS plus or extras? (hint hint) And maybe a Wiki on doing the swap? I'll try to make some notes when I have time to get around to upgrading dovecot on one of our servers, although I'm no wizard like so many working to provide CentOS.
I found that my bug report was a duplicate... I searched but nothing showed up.. but there was a report in April to RedHat. Still, from what I hear about the config, I would be surprised if they did anything more than a backport, since it sounds like dovecot 1+ has a lot of nice improvements.
Best, John Hinton
Could you please give the URL for the download. I'm looking at rpmforge site and all I can see is 0.99-14
I know it's a friday but...
Tony
I used this;
atrpms.net/el4-i386/atrpms/stable/dovecot-1.0.0-8_56.el4.at.i386.rpm http://rpm.pbone.net/index.php3/stat/4/idpl/4091766/com/dovecot-1.0.0-8_56.el4.at.i386.rpm.html
Andy.
On 6/8/07, Andy Wright centos@eltofts.homelinux.com wrote:
atrpms.net/el4-i386/atrpms/stable/dovecot-1.0.0-8_56.el4.at.i386.rpm
Andy/Chris -- any particular issues with upgrading from 0.99 to 1.0? We have a server that's been in production for about a year with 0.99 and strores many hundreds of unix-flat-file (often so-called "mbox" format) mailboxes as well as MH-style one-message-per-numbered file mailboxes. Our Outlook users occasionally have access trouble and I'd like to try 1.0, but not if it means breaking access to any of these mailboxes or having to go through a lengthy conversion process (we have a logrotate-style archival scheme that is tied to the present file layouts so conversion is non-trivial even if there is some kind of automated way to change formats).
no mbox conversion is needed. as mentioned before the only down side is that your pop users that keep mail on the server will redownload their mail as duplicates.
If anyone needs the rpm for fc4 let me know. I don't think it is on the net anymore.
On 6/8/07, Bart Schaefer barton.schaefer@gmail.com wrote:
On 6/8/07, Andy Wright centos@eltofts.homelinux.com wrote:
atrpms.net/el4-i386/atrpms/stable/dovecot-1.0.0-8_56.el4.at.i386.rpm
Andy/Chris -- any particular issues with upgrading from 0.99 to 1.0? We have a server that's been in production for about a year with 0.99 and strores many hundreds of unix-flat-file (often so-called "mbox" format) mailboxes as well as MH-style one-message-per-numbered file mailboxes. Our Outlook users occasionally have access trouble and I'd like to try 1.0, but not if it means breaking access to any of these mailboxes or having to go through a lengthy conversion process (we have a logrotate-style archival scheme that is tied to the present file layouts so conversion is non-trivial even if there is some kind of automated way to change formats). _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--On Friday, June 08, 2007 11:45 AM +0100 Tony Molloy tony.molloy@ul.ie wrote:
Could you please give the URL for the download. I'm looking at rpmforge site and all I can see is 0.99-14
Here's the latest Fedora version:
Issues in upgrading from 0.99 to 1.0:
http://wiki.dovecot.org/UpgradingDovecot
All bugzilla entries for component Dovecot:
https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=dovecot
Looks like RHEL also has a 1.0 update:
A little more digging turned up this page showing what versions are available for different distros, including various Fedora and RHEL versions:
http://wiki.dovecot.org/PrebuiltBinaries
My own plan is to grab the RHEL5 SRPM (which from the package name seems to be 1.0rc15), the upstream 1.0 release tarball, and rebuild a new RPM with the released version 1.0.
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`; }
On 6/7/07, John Hinton webmaster@ew3d.com wrote:
John Hinton wrote:
After about three years of this, it seems I have finally gotten somewhere near to the bottom of this.
The symptom:
Suddenly a user cannot download their email. Checking again through SquirrelMail, I get an error which says a log was written.
Going to the logs I see
"imap(username): Error indexing mbox file /var/mail/username: LF not found where expected"
Using Webmin's read mail module, I can see the messages. So, I move them to another account, but this is not yet the end of it. I was at first having to delete the mbox and then I'd send a test message in to recreate the mbox. But today, I tried a different tack.
I opened the now empty mbox in vi and found one blank line (LF). I deleted that line and then moved the mail back in and everything was fixed. So the line was still left behind.
The next time this happens, I'm going to try to delete a LF from the top of the mbox file to see if it is fixed without moving the mail.
I have read several places, although this is extremely difficult to track as there seems to be a multiple from address issue for some releases.. but anyway, I did finally find that dovecot .99 has an issue with leaving behind an extra linefeed at the beginning of the mbox. Deleting this linefeed fixes the problem. Supposedly dovecot 1 has fixed this problem.
I have found many reports of problems on Fedora and RedHat. Also, Debian has a closed bug report regarding this issue as they have moved forward to dovecot-1.0 and it doesn't have this bug. The issue seems to not have any relation to the mailserver, as I saw both reports of problems on at least Sendmail and Postfix.
Why are we still bugged with this? Seems that this is a bug that RedHat should be aware of?
The problem is it only rarely happens. I have no idea how to repeat the issue. It always seems to be an Outlook user, although that is by far the most prevalent email client in use by our users and it might just be chance.
So, what to do from here? Bug report to RedHat? This is most irritating! I can't even guess how many times I've fixed these mboxes. I'm about ready to toss dovecot in the trash until 1 becomes the RH standard unless there is a fix or upgrade from Redhat.
Thanks, John Hinton
Having had yet another of these errors, I was able to test deleting the first line in the mail file. Removing that single LF fixed the problem.
Still wondering what I should do as this is obviously something that is now very old and very irritating. It is a bug.
John Hinton _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
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@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.
- 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.
- 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 >>.
- 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.
- 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.
- 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@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Andy Wright -
Bart Schaefer -
Bazooka Joe -
Chris Mauritz -
John Hinton -
Kenneth Porter -
Michael Kratz -
Scott Lamb -
Scott Silva -
Tony Molloy