Weird amusement: #service qmail stop Stopping service qmail:# (for some reason, it never says "[OK]", wether you stop or restart) Run the "send 50 messages to hopeless@invalid.invalid" script. Wait for it to finish - doesn't report the mail() calls failed restart in a panic (it is a production box after all :P) service qmail start They seem to have processed normally, like it respawned qmail on demand of the php script requesting sendmail. Is that how it's supposed to operate? Also, reviewing the logs, it seems that it occurs in blocks... you'll get a bunch of failures for a few days, then none for 20 days or so at a time (the server typically gets 15-30 or so days uptime, and it's at 29+) -----Original Message----- From: fouldragon@aol.com To: plug-discuss@lists.plug.phoenix.az.us Sent: Wed, 11 Jun 2008 8:28 pm Subject: Re: PHP mail() woes Is it just me or is it surprisingly difficult to find information about how to configure qmail in the context of the ball of mess that Plesk makes it? I'm trying boosting ConcurrencyLocal to 40 and ConcurrencyRemote to 20 (twice the standard values), in the hopes it won't throw a fit when someone says "I want to have 15 deliveries open". Of course, I haven't been able to make it do it since like 2PM (which was when I was in maximum fury of throwing services up and down and poking helplessly at config files) so I can't tell what's helped. At the end of the day, though, I know what the 900 kilo gorilla in the room is. We have one site which hit the "close" page an average of 130 times per day this month so far... each one means at least five and possibly as many as 12 or so emails. I'm so glad I'm not with a host that caps outbound email (:cough: GoDaddy :cough:)-- I recall when the queues would backup 300, 400 deep with them. It's amazing how many people do not "get" the concept of a back-office they can log into regularly to check out things like orders. I can somehow imagine Michael Dell saying "Every order, I want to get an email on my mobile doohickey!" -----Original Message----- From: Floyd Arguello To: Main PLUG discussion list Sent: Wed, 11 Jun 2008 7:30 pm Subject: Re: PHP mail() woes I'm surprised that you don't have errors in your maillog. Anyway, php mail() opens and closes an smtp socket for each message... not a big deal unless you're hosting several email accounts on the site, then you have to consider that smtpd is called for every inbound message, etc... So increasing qmail-smtpd max connections might help, but if you increase it too much you could thrash your server. Replacing the native php mail might be a better solution. Try this: http://pear.php.net/package/Mail or find another one. Floyd On Wed, Jun 11, 2008 at 6:57 PM, wrote: > Looking at the logs for a few of the times it occured: > > 13:38:06-- finished spam-assassin processing one message, started > another, local delivery. > > 12:39:34-- Recieved an inbound message from SMTP land > > 10:21:12-- A message finished 2 seconds previous, a POP3 connection 4 > seconds later. > > There's nothing that looks out of the ordinary. Maybe the 'sendmail' > program or whatever part of qmail it maps to hit some internal limit-- > "There are 5 running, don't start a new one?" > > -----Original Message----- > From: Floyd Arguello > To: Main PLUG discussion list > Sent: Wed, 11 Jun 2008 6:41 pm > Subject: Re: PHP mail() woes > > > > > > > > > > > What do your maillogs show? > > Floyd > > > On Wed, Jun 11, 2008 at 6:19 PM, wrote: >> >> Oh, to add more details: >> >> I tried writing test code which would loop and call mail(). >> >> Wether I did 20 or 50 iterations, or even running two of the page that >> did 50 at the same time, to a local address, it still all worked. >> >> I also tried sending 50 to "test@invalid.invalid" (since I didn't want >> it to bother a real host), and it didn't report any errors at the >> mail() function. >> >> So it's obviously not just a "number of messages being sent" thing-- >> the only thing I could see is to somehow monitor all 100+ sites hosted >> on the server to see if something hits a critical point. >> >> >> >> -----Original Message----- >> From: fouldragon@aol.com >> To: plug-discuss@lists.plug.phoenix.az.us >> Sent: Wed, 11 Jun 2008 5:44 pm >> Subject: PHP mail() woes >> >> >> >> >> >> >> >> >> >> >> Several sites on the VPS I administer send out several "order >> confirmation" emails when a specific page is hit. >> >> Because of the way they run their businesses, it's non-negotiable that >> between 3 and ~12 messages are sent out on these occurences. >> >> The problem is that occasionally--- probably about one in 20 times > such >> a page is accessed, the server error logs fill up with: >> >> [Wed Jun 11 13:38:06 2008] [error] [client a.b.c.d] PHP Warning: >> mail() [function.mail]: Could not execute >> mail delivery program '/usr/sbin/sendmail -t -i' in >> /var/www/vhosts/xxxxxxx/httpdocs/feedback.php on line 54, referer: >> http://xxxxxxxx >> >> Since it tries to send a handful of messages at once, they usually > come >> in clumps of 5 or 6 messages like this. >> >> I tried correlating the times of the errors with resource warnings in >> Virtuozzo; no dice. >> >> I keep hearing that the PHP mail() call is not intended for bulk >> mailing-- but less than 20 messages at a shot is not bulk as I see it. >> >> The only thing I could see is some sort of resource exhaustion... like >> it can only have xxx mail() calls in the air at once, and it exceeds >> that limit. >> >> The server runs FC6 with Plesk 8.3 on top, so the mail setup is qmail, >> but it uses xinetd. I saw a few notes about being able to tweak >> qmail-smtpd to open more instances, but I'm not even sure that's >> relevant to the problem (since mail() calls are coming from local). >> >> What about replacing /usr/sbin/sendmail -t -i with >> /var/qmail/bin/qmail-inject - someone suggested this? Would that have >> any possible difference? >> >> And what's a good way to find out if this will repeat, other than >> sitting and monitoring the logs for an error? >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >> >> >> >> >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >> > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > > > > > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss