Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We use postfix and sendmail interface and are trying to send mails using the php mail() function and are getting the following error:

Could not execute mail delivery program '/usr/sbin/sendmail -t -i' in /var/www/html/xyz/temp.php on line 9

/usr/sbin/sendmail exists and has execute permissions

Server is a virtual dedicated server: Linux version 2.6.9-023stab051.2-smp (root@rhel4-64) (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)) #1 SMP Thu Sep 24 22:32:27 MSD 2009

postfix is running and we are able to send mail via telnet localhost smtp

This was running fine for the last two years and suddenly this error is occurring now.

There is a similar thread but is unanswered: Error: Could not execute mail delivery program '/usr/sbin/sendmail'

share|improve this question
1  
And what happens if you run /usr/sbin/sendmail from a shell? –  mailq Aug 21 '11 at 16:59
    
Can you show the result of the command: ls -las /usr/sbin/sendmail –  AndrewNimmo Aug 21 '11 at 21:25
2  
That's how questions stay unanswered: The asker asks some weired question and then disappears forever. And that's true for the linked question, too. –  mailq Aug 21 '11 at 21:29
    
Sorry guys, I was running late yesterday. I spent 10-15mins, didn't get reply so left..Btw, Today suddenly its working. Looks like some one on hosting provider end solved it. Sorry for bothering you. Thanks for your valuable time. –  Venu Aug 22 '11 at 8:17

1 Answer 1

up vote 1 down vote accepted

Oooh, a sudden change in the ability to execute external programs from within PHP? Sounds like someone's running on shared hosting, and their hosting provider suddenly decided to bump up the security on their servers (probably because they got massively pwned) and didn't bother to tell anyone (because "what could it break?"). In that case, you throw up your hands and move to a shared hosting provider that provides a professional service and doesn't go changing things for the hell of it.

In your case, though, that's probably a bit less likely, because you state you're on a "virtual dedicated server" (although the tortured terminology suggests marketroid interference, which is never a good sign). However, the fact that this has "suddenly stopped working" leads us inexorably to the same conclusion: something's changed, and whoever changed it didn't test things properly first.

So, what you do is review the change management history for the machine and identify what changed around the time that the problem occured. Or, since you don't have change management history (an assumption, but one I'm willing to put money on), you talk to everyone who has root on the box and ask them what they've done (if lots of people have root, then give up and build a new box with decent security and management policies).

You can also try and narrow down what's changed by looking in the package management logs (I think RHEL4 had logging of all package installs/upgrades, but I last touched RHEL4 two years ago, and I'm getting a bit fuzzy), command shell history, sudo logs (if you're real lucky), and doing strategic find -mtime -N runs to see what files are newer than whatever timeframe you've identified for service failure. Backups (assuming you keep archival backups, which you certainly should for configuration) can be helpful in identifying exactly what was changed.

Once you know what's changed, you examine the changes and try and narrow down what's gone wrong. Anything to do with PHP, your MTA, or your webserver are obvious immediate candidates, but don't go dismissing seemingly innocuous changes so quickly -- if you're not sure, keep it in the "possibles" list. Then you have the entertaining job of trying to reverse changes out until you find the problem. This is a pain-staking and laborious job, frought with peril, and if there's multiple changes that impact the problem, you'll likely be there a long time.

Sound difficult? Sure is. That's why you do the job properly to begin with (plan, test, document) and don't skimp on the details.

share|improve this answer
    
Much text for nothing. Not an offense! But you'll probably hear no response from the author. –  mailq Aug 21 '11 at 23:25
1  
I'm not writing for the OP, I'm writing for the thousand people who'll find the question via Google. –  womble Aug 21 '11 at 23:31
    
Although there's a lot of text there, there is a premise to the answer - check paragraphs 3, 4 and 5. –  Mark Henderson Aug 22 '11 at 2:28
    
Sorry guys, I was running late yesterday. I spent 10-15mins, didn't get reply so left..Btw, Today suddenly its working. Looks like some one on hosting provider end solved it. Sorry for bothering you. Thanks for your valuable time. –  Venu Aug 22 '11 at 8:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.