On 2024-07-05 05:19:01 +0200, Christian Schulte wrote:
> I have never seen an application performing such kind of checks.
Sendmail had a knob to refuse mail at a certain CPU load, on the
assumption that if a system was "too busy" it's in a bad state and
accepting mail would only make things worse. Also rogue(6) had CPU
checks, apparently they wanted to stop any rogue processes when the
system load got too high--maybe real work was being done? Speaking of
not checking the CPU, I have an amusing story of what a dual-processor
Linux box did at a CPU load of 5,000, something something sending the
wrong bytes to the wrong file descriptors, thus corrupting payment
transactions for a small internet retailer.
For application-specific filesystem checks I don't recall any off the
top of my head, but I tend to have monitoring send dire alerts when the
disk usage hits 90% (or less, if you want more breathing room to figure
out what is wrong, who to notify, them to act, etc) so would never have
seen anything that triggers at 5% free or whatever.
> If there is not enough space, write would fail anyway.
Or the filesystem gets somewhat looped after being run at 100% full for
too long. Granted, that was Windows, and we did warn the user not to do
that, but they did, and then when a nice Windows admin tried to backup
the 500G disk, it filled up a 3T disk and wanted more. Who knows what
breaks when a stray dd(1) or package update or whatever eats too much of
the remaining space. Not breaking randomly is probably a design goal of
a SMTP server that tries to guarantee delivery? You could fiddle with
the percentage, or remove the code, but I'm going to guess that most
everyone else keeps their mail partitions not so full.
No comments:
Post a Comment