[Watford] PHP - mail() function

[Yvan Seth]

Hi Walter,

A quick way to try to find the PHP error log is to force a log message.
Create this error.php file:

<?php error_log("ThisIsAnError: ASDFG12345") ?>

Put this on your server and visit it with your browser.  Next get a
terminal on the server and execute this (maybe as root):
    grep -lr ASDFG12345 /var/log
If the error was generated in any normal log file then this command
should tell you the name of the file.   If this points out a file then
while you try running the mail script have this running in a terminal:
    tail -f <filename>
Any new additions to the file that occur while you're testing will come
out on the terminal.

See for more info:
    http://uk2.php.net/error_log


A verbose response follows... but may just confuse things, hopefully the
point above works out and you can avoid my attempt to describe a system
of many variables :)

<quote who="walt">
> I was looking for the logs but Linux is like a rabbit warren, I can
> never find anything or I have to read reams of stuff to track it down.
> Which is why I asked the question,  are there any logs somewhere.

Under Linux things are (typically) compartmentalised using the
file-system and based on "what it is" rather than "what it belongs to"
(as opposed to the usual mapping on Windows where the file-system
arrangement is more "what it belongs to", i.e. "C:/Program
Files/MonkeyFoo/Thing").

As you have probably noticed, you should generally find all the logs you
need in "/var/log" with reasonable file/directory names.  Unfortunately
the names of the log files can differ greatly from distribution to
distribution, if that weren't the case this email would be *much*
shorter :(  However for the Apache log, based on SLES10 (maybe someone
familiar with Open SuSE can point out the exact locations of the log
files?), you may find it at:
    /var/log/apache2/access_log

And, maybe the most important for you right now, the Apache error log:
    /var/log/apache2/error_log
But sometimes PHP errors go to their own log file so look out for
something like:
    /var/log/apache2/php.errors
If you can't find anything relevant you might want to run:
    find /var/log -iname '*php*'

Some alternatives to the "apache2" directory are: "httpd", "apache", or
"www".  (The variables stack up!)

If you CD to /var/log and ls/cd around you should get a feel for where
things are.  Note that for many logs you may need to be logged in as
root to be able to read them.  

Once you've found the Apache or PHP error log I recommend running this
in a dedicated terminal while you're developing:
    tail -f /var/log/apache2/error_log
    (or the PHP error log if it is separate, or one for each even)

This way you'll see any errors when they happen.

> If I then tried the next test:
> 	/usr/sbin/sendmail -v  walt at helvatron.co.uk
...
> 250 2.0.0 lB38ntvG004568 Message accepted for delivery
> walt at helvatron.co.uk... Sent (lB38ntvG004568 Message accepted for delivery)
> Closing connection to [127.0.0.1]

That looks fine, you did get this second email I presume?

> And after all that I managed to track down the log under /var/log/mail
> which contains no entries about mail() attempting to connect.

Then your script is probably not initiating the connection at all and
your next step is to check the Apache logs to see if it is generating
any useful errors.  (Note that the log probably wont make any mention of
"PHP" or "mail()", from the PoV of the MTA this is just "something"
that's connected to it.)

> I have no idea yet where to look for the queue (MTA) file/folder/logs.  

The /var/log/mail is the log file for all MTA actions.  My advice is to
stick to monitoring this log file and not worry about the
mechanics/location of the queue (which will normally be somewhere under
/var/spool).

> There are 2 php.ini, /etc/php5/apache2  &  /etc/php5/cli.  I am
> assuming its the one in apache2 I need to change and I have set
> 'error_reporting=E_ALL' .

So your "tail -f" might show something useful about the mail() call.
Can always hope. :)  


Sorry about the verbose email.  A difficulty with Linux is that when the
problem isn't in front of you the response to "X is broken" is often
"what X are you using, on which distro (and which version), with which
Y, and what about Z?".  Once you're familiar with the patterns the exact
values of X, distro, Y, and Z aren't so important - so long as you have
the problem in front of you.  

Somebody at the LUG meeting can probably make this work for you in under
a minute once they can see it in person!

-Yvan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.lug.org.uk/pipermail/watford/attachments/20071203/c56ceff5/attachment.bin