(1) What version of sendmail are you running?  (Are you even running sendmail? or a sendmail compatable MTA?)

(2) When you say "Sendmail runs fine from the command line" are you passing a full email on stdin using the same command line switches as specified in your php.ini?

Does libclntsh.so.9.0 exist anywhere on your system ( try: `find / -name libclntsh.so.9.0 -print` ).  Does the path where that file is located exist in your /etc/ld.so.conf ?  If you've just added it did you remember to run `ldconfig`?

In any event, this is a sendmail problem and not a PHP one as PHP does not use libclntsh itself.

I am running sendmail version 8.12.7. When I say that I can run it from the command line I mean that if I execute at the command line the value of sendmail_path from php.ini, it works fine. In fact, if I do an ldd on sendmail it doesn't even NEED libclntsh.so.

Yes, libclntsh.so.9.0 exists in $ORACLE_HOME/lib and I added it to the LD_PRELOAD environment variable for Apache.

As I said, all other services based upon PHP-Oracle work fine except the mail command.

Try the following script (which mimicks the core of mail()'s functionality) and reply with what is returned:

<?php
  $fd = array(0=>array('pipe','r'),1=>array('pipe','w'),2=>array('file','proc-open.error.log','w'));

  var_dump($pid = proc_open(ini_get('sendmail_path'), $fd, $fp));

  /* Replace this with a mail address you have access to */
  fwrite($fp[0],"To: your@emailaddress.com\r\n");
  fwrite($fp[0],'Subject: This is a test. ' . date("n/j/Y H:i:s") . "\r\n\r\n");
  fwrite($fp[0],"This is only a test.\r\n");
  fclose($fp[0]);

  while (!feof($fp[1]))
    echo fgets($fp[1]);
  fclose($fp[1]);

  var_dump(proc_close($pid));

  echo "---------------\nEnd of script\n------------\n";

  readfile('proc-open.error.log');
?>

The mail is successfully sent. At the command prompt I get:

resource(7) of type (process)
int(-1)

I did NOT compile php with --with-oci8=shared,/usr/oracle/OraHome1 (well, I did, but then PHP complained that the OCI functions were undefined).

This may be more related to apache than PHP, though I cannot think of why.

Well then, let's try taking Apache out of the equation.

Use the CLI version of PHP (which should have been built along with the Apache DSO module, unless you explicitly specified --without-cli) with a simple mail script:

#!/usr/local/bin/php
<?php
  mail('your@emailaddress.com','This is another test','Still just a test.');
?>

Sorry for the confusion. The last output WAS from the CLI. This is the output from the page served up by Apache.


resource(5) of type (process) 
int(-1) 
--------------- End of script ------------/usr/sbin/sendmail: error while loading shared libraries: libclntsh.so.9.0: cannot open shared object file: No such file or direct

I can't see this as anything but a non-PHP related error at this point.

It's *really* odd that the error only occurs when a fork is issued, though that may be an artifact of the way in which Apache2 handles children.

I'd say spend some time working with the apache configuration file, paying particular attention to the use of LD_PRELOAD which you mentioned you're using.

In any event, the fact that the exact same script works under CLI but not under Apache DSO is very suggestive.

I had the same problem
with any PHP/Oracle version (since 4.0.6 or oracle 8,9,9.2)
Actually it's not directly related to php/oracle.

Here is the trick that solve the probleme:

Since i use he Apache server included with Oracle distribution i couldnt re-compile it myself.
So Oracle apache needs tweking of apachectl start file in order to suport php as a dso.

it needs LD_PRELOAD of libclntsh.so.X.0 AND libpthread.so since it's not compiled with libpthread ...

LD_PRELOAD=/usr/lib/libclntsh.so.8.0:/usr/lib/libpthread.so
export LD_PRELOAD

since u're asking a LD_PRELOAD of libclntsh this library will be needed by any programs runed by apache.
so sendmail when lunched by apache will inherit the needs of libclntsh.so.X.0, this problems is not specific to "sendmail" but to most binary run from apache.

Curiously for this to works you need to ld_preload the FULL PATH of the libs and not relaying on the library being in som environement PATH.
Olso for me it worked after symlinking my oracle lib (in $ORACLE_HOME) to /usr/lib/ or som well knowns libs path and not directlly of oracle home, even with fullpath (maybe a ld.so.conf prob).

Hope this will help fixing u're probleme