I'm trying to pipe email sent to an address to a php script.
I've put in the Feed to Program in the email aliases file.
The php file has permissions 6755. That gives everyone exectution access, and has it run as the group of the folder so it will have access to everything in the folder. All of the directories down to the script have the permission List granted to everyone. The final directory has Read granted to everyone.
When I send an email to the address, I get nothing.
The php file consists of,
#!/usr/bin/php <div class="codeblock"><pre><code><span style="color: #000000"><span style="color: #0000BB"><?php<br /> </span><span style="color: #007700">&</span><span style="color: #FF8000">#10;echo 'got it'; <br /></span><span style="color: #0000BB">?></span></span></code></pre></div>
If the path in the alias file is incorrect, it reports a "Could not open input file:" error.
I believe that it should be sending me a response saying 'Got it'.
I've also tried to change the file to
#!/usr/bin/php <div class="codeblock"><pre><code><span style="color: #000000"><span style="color: #0000BB"><?php<br /> ob_start</span><span style="color: #007700">();&</span><span style="color: #FF8000">#10;echo 'got it'; echo ' PID:'.getmypid(); echo ' GID:'.getmygid(); echo ' User:'.get_current_user(); $logfile = fopen('bcastlog.txt', "a"); $log = ob_get_contents(); fputs($logfile, date( "Y-m-d H:i:s", time() )." $log\n"); fclose($logfile); <br /></span><span style="color: #0000BB">?></span></span></code></pre></div>
which should log the information into a log file. Again, nothing happens and I can't find any error logs to look at.
Of course, these scripts all run via the web...
If the path were wrong, it should give me the could not find input file error. If permissions were preventing access, I should see a Permission denied error. (These would both be part of the bounceback, which is fine during testing. I'll suppress that later.) But I'm not getting ANY feedback at all. Nada.
<I know that the email is going to the proper address because I've also set the alias file to forward it back to me and I'm receiving the original message. Also - I've looked in the messagelog and see,
to=<XXX-XXX.com@rhost1.XXX.com>, orig_to=<XXX@XXX.com>, relay=local, delay=0.22, delays=0.13/0.01/0/0.08, dsn=2.0.0, status=sent (delivered to command: php -c /home/XXX/domains/XXX.XXX.com/etc/php5/php.ini -f /home/XXX/domains/XXX.XXX.com/public_html/echo1.php) so it is going to the proper place.>
Any help is greatly appreciated.
Thank you, Rob
Well, if you were running that PHP script from cron, it would indeed be generating the text "got it" in an email to the user who owns the crontab.
However, when an email is piped into a script such as what you're doing -- printing text from that script isn't emailed anywhere.
To send an email, you would actually need to use PHP's "mail" function from within your PHP script.
Here's a confession - it was sending the email with the 'got it' as a bounce. Then it stopped. And now it won't anymore... I don't know what I did. I was trying to move the 'got it' within the actual desired script to measure progress as to when it would fail. But now I've backed out all of the desired script, started over from scratch and get nothing...
Even with that, I can't get it to log anything to the disk. Effectively, it is 'running the script' (or thinks it is) but not doing anything. And there are no error logs anywhere.
I'm baffeled. I've tried running dos2unix on the script, just in case (I do my editing from a Windows box, but I never have this issue anymore.)
What happens if you run that script manually, from the command line?
You may want to take a peek in your mail logs (/var/log/maillog and /var/log/mail.log), as well as your procmail log (/var/log/procmail.log) to see if any errors show up in there.
If I run it from the command line, it gives me the various IDs and writes them to the log file.
I just updated the log file path to be absolute, not relative. I resent an email, with the same results.
The /var/log/maillog shows the message getting 'delivered to the command' with no further feedback.
There's nothing in the procmail.log file. That's probably because it is being piped via an alias.
I know all of this is pointing to a permissions problem. But for the life of me, I'm baffled as to where it could be. And why wouldn't it report a Permission Denied error?
I appreciate your help, Rob
OK, so I just tried something, with somewhat surprising results.
I changed the pipe command to include 2>/path/to/error.log
It gave me a couple of permission errors, until I opened up that directory's permissions to 777. Then it created an error.log file, but it was empty. The surprising results were that it was owned by 'nobody'. And that, even given the opportunity to log its errors, it didn't log any errors, and wasn't able to update the bcastlog.txt file.
Thank you, Rob
What if you use that log file to capture the scripts output, rather than errors... does the script perhaps generate some output that's not considered an error?
OK, if I run the command with ">>/path/to/logs/output.log" and "2>/path/to/logs/error.log", it creates both files and puts the expected output in the output.log file.
Then I deleted both files and sent an email to the address. It created both files again, but didn't put any contents in either one. The permissions on the logs directory are 777 and it is creating the files with 600 permissions. I changed the permissions to 777 and resent an email. Still, empty files.
Man - this is frustrating!
OK - it turns out that it is writing the output to the output.log file. Apparently the program I was using to look at it wasn't downloading it, so I thought it was empty.
It still isn't saving anything to the log file (bcastlog.txt) and the error.log is still empty.
At this point, I have little faith that it'll be able to do what I'm going to ask (read the message and submit a SOAP request based on the contents), or even if it'll be able to give me progress status. But I'll try and post more if it gets to a dead end.
Thank you, Rob
OK, it looks like I finally resolved the problem. It was because the current working directory was not the same as when executed by a web page. So I added,
to the top of the 'master script' (the one being called). That forces the working directory path to be the same as the master script (which is also the same as when called by a url).
Hopefully this will help someone else.
Eric - thanks for all your help!