[RESOLVED] Script Works from WWW but not as Cronjob

rsmith

I'm using a script to generate a log file for the current day. When I run it from a web browser it works flawlessly, however when I try to schedule it as a cron job, it fails.

I set it to run with the same permissions as the WWW subsystem but no file is created.

Here's my script:

<?php
	$date = date("Y_m_d");
	$logfile = $date.".log";

$handle = fopen($logfile,"w") or die("Cannot create file");
fclose($handle);
?>

Should I just use exec() and execute mkfile then set the proper permissions? Obviously the directory is writable and the permissions on it are set properly otherwise running it from the browser wouldn't work.

johanafm

rsmith;10997213 wrote:
I'm using a script to generate a log file for the current day. When I run it from a web browser it works flawlessly, however when I try to schedule it as a cron job, it fails.

And exactly how does it fail?

rsmith;10997213 wrote:
I set it to run with the same permissions as the WWW subsystem but no file is created.

In other words, the file is not created, because...?

rsmith;10997213 wrote:
Should I just use exec() and execute mkfile then set the proper permissions?

No, you should figure out why fopen doesn't work and then fix the problem.

rsmith;10997213 wrote:
Obviously the directory is writable and the permissions on it are set properly otherwise running it from the browser wouldn't work.

Except that you are NOT running it from the browser. So, obviously the directory is writeable and the permissions on it are set properly for the web server.

The error log will tell you what is actually happening.

jeepin81

i believe since you're running this script via cron you will need to put the entire path to your log file starting at '/'.

rsmith

@ - It fails in that the die() message isn't output to the screen and no file is created in the CWD

@ - I use the full path. I have several other PHP scripts that are scheduled cronjobs but this is the only one not functioning properly.

All scripts used the same credentials. To reiterate, it works perfectly when I initiate through the web browser.

bradgrafelman

All scripts do not use the same credentials. When you view it from the web browser, the web daemon (e.g. Apache) is the one who is invoking PHP, thus you're using the web server's credentials.

Cron jobs do not go through the web server, thus they do not use the web server's credentials.

rsmith

I understand that; what I meant was that the other scheduled cron jobs are using the same credentials as the ones configured for this job that is failing. I have even tried using root.

Either way, I resolved it by coding in a workaround into the actual script that would invoke a log file entry. Simply checks to see if the file exists, if it doesn't it, it creates the log file. If it does, it appends to it.

Thanks anyway everyone.

johanafm

My entire former post tried to tell you

E_WARNING: Check your error_log

This post will start by telling you

FATAL ERROR: Error_log remains unchecked

since this would have provided the reason for why fopen failed to create the file.

But, while the above would have been good, let's have a quick look at everything else you claim instead

Initially: file isn't created.
Now: file isn't created in CWD (current working directory) and no die message is shown

If you had checked your error_log it should in this case have been free of error messages since fopen apparently succeeds (otherwise you would have a die message). This does not necessarily mean that you get a file in your CWD.

You also claim you are using a full path, which makes me wonder
1. Why doesn't your posted code use a full path?
2. If you have a full path, why do you even mention CWD at all?

Why do you tell me that all your other scripts are working? This information is irrelevant.
"I have several cups and glasses at home and only this one is broken. It's not even red."
"I have also tried drinking from an identical-looking cup at work and have no problems at all with it."

rsmith

johanafm;10997253 wrote:
You also claim you are using a full path, which makes me wonder
1. Why doesn't your posted code use a full path?
2. If you have a full path, why do you even mention CWD at all?

Why do you tell me that all your other scripts are working? This information is irrelevant.

He was making reference to specifying the full path of the php file in my cronjob details, which I did. I do not need to use full paths in my script as the output is relative to the location of the script on the webserver.
CWD was used to represent that the script, when executed from the browser, was generating the file in the directory in which the script resides, ergo CWD.

Nothing is irrelevant there. I was providing supporting information to verify credentials weren't the issue.

Thanks for the cynical, holier-than-thou response. It's very helpful. The only thing that would've made it more beneficial is posting it before I found a workable solution. Now it proves to be just an exercise in futility and trolling.

Derokorian

You might try using a full file path for your cron script. I had a similar issue with a cron job that created its own log file, I solved it by using dirname(FILE) :

$log = dirname(__FILE__) . DIRECTORY_SEPARATOR . date('Y-m') . '.log';

Taken from my script. I was getting no errors previously but I couldn't find the files. I now always use full paths for all file operations (fopen, include, getimagesize, etc)

bradgrafelman

rsmith;10997265 wrote:
the output is relative to the location of the script on the webserver.

It isn't in the code snippet you posted above; its output is relative to the CWD (which may or may not be the same directory where the script is located; for cron jobs, it most likely is not).

johanafm

rsmith;10997265 wrote:
The only thing that would've made it more beneficial is posting it before I found a workable solution. Now it proves to be just an exercise in futility and trolling.

I just tried to get you to realize yourself that what had been posted before to help you out actually was the information you needed to resolve the issue (with fopen, not the workaround replacing the functionality of fopen).

And that includes knowing
1. that fopen did create a file
2. that it did not place it where you thought it would
3. that error logs are useful
4. that what happens in your php environment depend on the actual php environment used

So if you actually started by assuming that input from other people is there to help you, you might actually get the help you need. If you assume it's there for trolling reasons, well then it's likely to be just that because you take it that way and miss noting the information which is there.