jethro at freakzilla.com wrote: > > Hey, > > Quoting Bob Tanner <tanner at real-time.com>: > > > % mailq | wc > > 680 3111 38830 > > 680 "transient" message. I think users would be pretty upset if I lost > > almost 700 messages. > > First of all, that's not good (; Is it because of downed hosts, or just slow > queue? > > Second, I'd say ignore the errors. All they're saying is the file was there > when it gathered up the information, and not there anymore when it went to back > it up - because it was already processed and delivered. > > If you want to try and avoid those messages, try backing up that directory > seperatly from the others. > > You'll still probably get those messages. The only way I can think of to avoid > them really is to shut down mail while backup's going on which it doesn't seem > like you'd want to do (; > > -Yaron > It isn't strictly necessary to shut mail down while taking a backup. Just "renice" all currently executing copies of sendmail to "+20" before backing up /var/spool/mqueue, and then restore their priority to "0" afterward. Doing this effectively prevents those copies of sendmail from being scheduled in the run queue unless there's absolutely nothing else to put in there... and since your backup script will be running, there will be. Of course, this'll work best (i.e.: effect mail delivery the least) if you only do this while backing up /var/spool/mqueue. I.e.: #!/bin/ksh # # wrapper for backing up /var/spool/mqueue when using sendmail # (Needs to run as root) # # first, grab a list of pids running sendmail... PID_LIST=`ps ax | grep sendmail | grep -v "grep sendmail" | \ awk '{ print $1 }' | xargs echo` # next, force priority all sendmail pids to +20 for i in $PID_LIST do /usr/bin/renice 20 $i > /dev/null 2>&1 # ignore output done # Invoke the backup script for /var/spool/mqueue DO_BACKUP /var/spool/mqueue # reestablish "normal" priority for sendmail pids for i in $PID_LIST do /usr/bin/renice 0 $i > /dev/null 2>&1 # ignore output done Hope this help'idly, -S