Florin Iucha wrote: > > On Sat, Dec 08, 2001 at 01:22:56AM -0600, Steve Siegfried wrote: > > It isn't strictly necessary to shut mail down while taking a backup. Just > > "renice" all currently executing copies of sendmail to "+20" before backi= > ng up > > /var/spool/mqueue, and then restore their priority to "0" afterward. > >=20 > > Doing this effectively prevents those copies of sendmail from being sched= > uled > > 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. > > I am not sure I agree with this. If process A is niced 20 and process B is > whatever and process B is blocked for IO... process A runs! > > [Do try it at home:)] > > florin > Well, if you're running in "benchmark mode" (single-user with no other logins, daemons or other background noise), then this might be true (why you'd be running sendmail in this scenario is beyond me, but that's another matter ;-). However, on your typical production Linux box, especially a server, a "ps ax" will show you that there's almost always enough processes in the run-queue that will see scheduled cycles long before any copies of sendmail running at priority 20. Add to that the fact that the vast majority of files in /var/spool/mqueue are there because sendmail (running at any priority) wasn't able to establish a network connection to the receipent's email server during the first "N" tries. Thus, over the short haul (the time necessary to copy /var/spool/mqueue to a different disk-based filesystem, like /mnt/backup/var/spool/mqueue), it's extremely unlikely the "unable to deliver mail to mail.foo.com" situation will change on the "N+1'st" try. However, we need to stop and consider that what we're trying to accomplish here is to back up /var/spool/mqueue (which, on a well balanced and configured machine, seldom gets "large"), but with the following caveats: 1- sendmail will be running because the admin doesn't want to shut it down, and 2- it's okay to not backup email that was present in the outgoing queue when the backup was started, but was sent prior the backup reaching that particular inode in the filesystem. However, because typical admins get nervous when seeing "can't find file X" type messages, we want to try to keep the number of times caveat #2 pops up to a minimum. Short of 1) hacking sendmail so it always checks for the existance of a file like /var/spool/mqueue/.currently_doing_a_backup_please_wait_till_I_finish before actually sending any email, or 2) writing a custom backup program that ignores "missing files", the approach I'd previously outlined using renice(8) ought to work well for 99.5% of all folks who want to regularly back up directories like /var/spool/mqueue. As for the other 0.5%? Well, they can either shut down sendmail or try something extremely silly like: ifconfig eth0 down; DO_BACKUP /var/spool/mqueue; ifconfig eth0 up -S