> Hmm, I see. > > at worst you now locked yourself out. >> > I've already got the ext4 reserved blocks covering for that. Of > course, not every file system has something like that. > Even with reserve blocks it is still quite possible to fill the disk up past the reserve blocks. Never rely on a feature like that to save you from yourself ;), Ive had a few systems that were a fun disaster because the disk hit 105% full.
> > But also every MTA does this also and you will be hard pressed to find >> one that doesn't. >> > Indeed. postfix, for example, has a limit of 1.5 × message_size_limit. > Way more sane, imho. > Im not advising the limit is sane, it should/could be a knob, which is probably a discussion to have now. To be fair I as the admin should be able to decide how much I want to fill my queue folder, since in all fairness my queue folder could not be in /var/spool I could have moved it to a san where it shares space with other mission critical applications and has 50 terabytes of storage, and I really don't care if the disk fills past 5% because really it wont effect anything for the disk to get to near zero and I will always be able to recover from it filling. > > but that means your script or app needs to learn to be more resilient >> > Any standard solutions for cron/at to do that? > Standard no, many ideas, yes. If you just bebop around the internet there are many great examples of scripts that are resiliant. Since Im not sure what your scripts are written in I can only give you generic advice which is if you use the sendmail sender as the wrapper it should return a success/fail result and you could case or if/else for that result so it becomes in essence: Check for unsent queue and try to send Try to send new mail if Success exit if fail count=1 try again if fail count=2 write mail to disk (maybe pickup directory so it will get sent at some point when the mailer recognizes it) -- Jason Barbier | [email protected] Pro Patria Vigilans
