Alex J. Avriette wrote: > The MX chewed and chewed and chewed, but eventually OpenBSD's > otherwise fairly stable kernel panicked. I suppose it can be > forgiven for this, as the load was around 30 as it processed many > emails, each one launching its own sa process, which then tried to > read the disk, became io blocked, and so on.
I would not be so forgiving myself. A UN*X kernel should not panic in this situation. You might run out of resources otherwise such as memory or process slots. But a true panic would be either a hardware problem or a software bug. Either way it is bad and something to be fixed. As far as a load of 30 that is probably related to the defined default number of mail transport processes that are configured. Most MTAs of sendmail's era and later throttle themselves when the load gets too high. In those situations the machine will find an equilibrium at that level. If each process spawns one SA process then the number is probably half of the load you saw. The number is a compromise between totally killing the machine and refusing connections when the system is throttling back. If the connection is refused the mail will remain in the other systems queue and it will be retried again. Sorry but I do not know enough to comment on your bayes database issues. Bob
pgp00000.pgp
Description: PGP signature
