There is definitely a relation beetween the 'thread.cfg' settings, and the nature / frequency of smtprcv crashes
Based upon a post from Woodie ( below ), my thread.cfg was configured as : 1,1 ( since july, 2003 ) As a reported here, I had increasingly frequent problems with smtprcv On monday, I could'nt even restart the server without smtprcv stopping in the next minute. I then decided to change thread.cfg to 100, 50 and ... yeah, everything was working fine and fast... until a Dr Watson but only 24 hours later. ( note that we were wondering why Chairman had Dr Watson errors, while some others just had smtprcv stop ; it might be because of different thread.cfg settings ) So my preliminary observation is : - too little thread.cfg parameters : smtprcv stop working and you cannot either stop it nor restart it > server reboot necessary - too big thread.cfg parameters : dr watson ; ( Chairman's script to detect Dr Watson, stop and restart, is efficient in this case ) I'm now back to the suggested 40, 20 in the documentation, I'll play with these parameters, in the hope to find some correlation that makes sens, and minimize crashes Do anybody know what theses parameters exactly do ( minimum and maximum # of message threads ??? ) I can imagine that 'maximum' is kind of simultaneous processing the program supports, but what would 'minimum' be ? Benoit <quote> Sent: Monday, July 28, I can't remember if you can just replace your old version with 3.3d or if you have to reinstall it, but here is my thread.cfg file. I do remember something about 40 threads causing a problem and it's best to set it to 1 like this: 1 1 //--Comments allowed below this point!--// Line 1 - Maximum # of message threads Line 2 - Minimum # of message threads Hope this helps. Woodie Sayles This is the discussion list for the IMS Free email server software. To unsubscribe send mailto:[EMAIL PROTECTED] Delivered by Rockliffe MailSite http://www.rockliffe.com/mailsite Rock Solid Software (tm)
