> Also, I wonder what the point of having a sanity check against > kern.maxfiles at all is, especially with the arbitrary-feeling > additional rule of "maxcon may not exceed kern.maxfiles - 200". It feels > redundant to me, and it sort of makes a promise of protection it can't > uphold.
That code predates the addition of getdtablecount(). Maybe someone can think about improving it. > I mean, it's a system-wide limit and spamd has no control over the > resource usage of the rest of the system, so it still has to (hopefully > gracefully) handle the case when it runs up against either kern.maxfiles > or RLIMIT_NOFILE. Graceful recovery can include the heaviest programs avoiding getting to that point. Shrug. These are just descriptors. But honestly, a lot of programs don't know how to cope correctly with ENFILE and EMFILE. benno and I put a lot of effort into improving this about 3 years ago for the most sensitive programs, but fixing all the programs is a harder job. > Removing that check at least simplifies that part of spamd's pledge(). Yes that covers up a scratch on one deck chair.
