> Hi Sam, > > so what should I do now ? > As I can remember, I decreased that value to 20 or 10. > A long time ago I had 40 and during this time I had no problems with > crashing.
It's not the number of processes that is the problem, it is that the parent process is attempting to log a warning to a non-existent logging facility. Raising this number will only hide the problem at the cost of depleting resources, it is still possible to reach the error condition under high load. ---IMPORTANT PART--- Again, the most probable cause is that in your esmtp configuration file there is an incorrect path set for the logging facility: TCPDOPTS="-stderrlogger=/usr/sbin/courierlogger" Confirm that that path is really pointing at the appropriate logging facility (courierlogger) and has appropriate permissions for the daemon to write to. ---END IMPORTANT PART--- > > So what is to do, or better what is your suggestion. > Should I try now to trace the comm.flow or is that enough, what Jason > Benguerel wrote > that you will take care of that problem if you have to less processes and that > then it > could be possible for spammers to crash the MTA? Spammers did not crash the esmtp daemon, my misconfiguration did. You should not wait for a patched version, you should fix your configuration as outlined above. If Sam makes any changes it would most likely be to immediately die with a trout slap* to fix your configuration. (Although theoretically many bad things could conceivably happen to the logging facility after initial startup, I'm not sure if there is an appropriate logging facility of last resort to revert to rather that just dying or soldering on with no logging at all.) > Many Thanks again for your help. > > Cheers, > Maik *warning ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
