a different approach was used for this, we reserve 100 blocks at startup which is what Sendmail does on OpenBSD, if it has worked for years, it should keep working.
On Tue, May 20, 2014 at 02:29:41PM -0700, Barbier, Jason wrote: > restart away good man it is a topic that should be discussed because we > honestly should beable to set when it decides to reject since as some one > pointed out 5% of a 1tb disk is like 50gigs, and no where near full. > > > On Tue, May 20, 2014 at 12:20 PM, Gilles Chehade <gil...@poolp.org> wrote: > > > This has not been forgotten, the conversation with fellow hackers has led > > to nowhere but I'm about to restart it with a diff :-) > > > > On Tue, May 13, 2014 at 03:35:56AM -0700, Barbier, Jason wrote: > > > > 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 | jab...@serversave.us > > > Pro Patria Vigilans > > > > -- > > Gilles Chehade > > > > https://www.poolp.org @poolpOrg > > > > > > -- > Jason Barbier | jab...@serversave.us > Pro Patria Vigilans -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
