[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 353
  • Last Modified:

Having troubles with a cron job running a php scirpt

I am trying to schedule a job to run a php script using cron.  I have ran the crontab -e command and place in something similar to this
MAILTO=me@mydomain.com
00 13 * * * /usr/bin/php /path/To/my-script.php

This should try to run every day at 1pm, which it does, however the response I receive is "Could not open input file: /path/To/my-script.php."  This seems to be a rights problem with cron being able to access the file because if I copy "/usr/bin/php /path/To/my-script.php" and paste it into the command line, it runs just as expected.
0
chshrmc
Asked:
chshrmc
  • 19
  • 11
  • 5
1 Solution
 
2266180Commented:
each cron job will run in the user credetials of the owner. so a cronjob created with the  user "abc" will run as that user and will not be able to access resources to which it doesn't have access to (like other users files). so it's all in the "/path/To/my-script.php"
0
 
chshrmcAuthor Commented:
how would I set this job up to run as root so it has super user privledges?  I created the job while I was logged in as root.  I didn't really specify a user to run it as.  I just did crontab -e and edited the file.
0
 
2266180Commented:
did you log in as root or did you "su"? you should log in normally as root. if you can't, then use "su -"
0
NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

 
chshrmcAuthor Commented:
I logged in normally as root
0
 
chshrmcAuthor Commented:
I have also made sure to run "crontab -u root -e" while running as root in order to edit the file, but of course have also tried it as "crontab -e" while running as root
0
 
2266180Commented:
could you post the results of:

ls -l  /usr/bin/php
and
ls -l  /path/To/my-script.php
?
0
 
chshrmcAuthor Commented:
ls -l  /usr/bin/php
-rwxr-xr-x  1 root root 1379641 Jul  1  2004 /usr/bin/php

ls -l  /path/To/my-script.php
-rwxr--r--  1 root root 2457 May 18 11:01 /path/To/my-script.php

of course names have been changed to protect the innocent
0
 
2266180Commented:
everything looks fine. weird. I would guess in this case that either your real path has some issues, or there is something php (as in program) specific.
in order to debug this:
create a basic php script that creates a file in /tmp say "php_test" with some garbage in it.
create the following shell script:
#!/bin/sh
cp  /path/To/my-script.php /tmp/php_original

then add another line to the crontab that will execute this shell script (put it somwhere accesible (like /tmp) and modify the other crontab entry so that both lines will execute say every 5 min and the first job will execute this basic php script you just created instead of the original one. and place this script in /tmp as well). after they were executed cancel the crontab second job and modify the first one to it's original state so that it will not interfere with the "debugging"
now go in /tmp and see what files are in there.
if the php_test is there with correct garbage, then php executes just fine
if the php_original is there with correct content, then crontab executes correctly AND can access the original php script.
if both files are there, we need a second test. modify the original crontab job to execute our test php script and move the script from /tmp to the original php srcipt dir. and don't forget to delete the /tmp/php_test file.
after the job is executed, check if there is a /tmp/php_test file with the correct garbage in it.
if it is, then there is something wrong with your php script. if it isn't I'm lost because that means that even though the script file is accessible (se previous test) and php executes correctly, it still cannot execute the php script. in this case you can start by moving the original script to /tmp this will eliminate the path problem. then you can chmod 777 the php script and see if it still doesn't execute.
I'll try to think of other possible causes just in case none of the tests above solve the mistery
0
 
chshrmcAuthor Commented:
Seems like I'm still having similar issues after doing this.... I created a /tmp/php_original just as you said and I tried creating another php file that just creates junk in a file.  After they didn't work the first time, I did a chmod 777 /tmp/php_original and /tmp/test_script.php and both failed errors are as follows:
Could not open input file: /tmp/test_script.php.
/tmp/php_test: /tmp/php_test: No such file or directory
0
 
2266180Commented:
seems that php doesn't see the files. I'll have to install php and see what's up with it. could you paste the code of the test_script.php the one with writing junk in a file because I know nothing on php. also, the version oh php would be a good idea, just to be in sync.
0
 
chshrmcAuthor Commented:
here's my code to write this to a file in /tmp called test.... I'm using PHP 4.3.4
Also keep in mind that if I run from the command line the exact commands that I have in my crontab file, it works perfectly.

<?php

  echo "This is a Test!";
  entrytofile ("Bunch o junk","test", "/tmp");
 
function entrytofile($info, $name, $dir)
{      
      //add slashes just incase there are multiple spaces
      $dir=addslashes($dir);
      // Open the file and erase the contents if any
      if($file_conn = fopen("$dir/$name", "w"))
      {
            // Write the data to the file
            $write=fwrite($file_conn, $info);
            // Close the file
            fclose($file_conn);
      }      
}
?>
0
 
ahoffmannCommented:
is any part of $dir a symbolic link?
0
 
chshrmcAuthor Commented:
no, just a direct link
0
 
ahoffmannCommented:
what is a "direct link"?
0
 
chshrmcAuthor Commented:
no link really sorry, just a regular directory and a regular file... not familiar with the term for it, but its a normal file created by
"vi /path/To/my-script.php"
0
 
2266180Commented:
hm ... let's just make sure, ok? :)
do a ls -l on all compnents of the path.
in your example you will do a:
ls -l /
and copy the line that contains "path"
then
ls -l /path
and get the line with "To"
and so on.
0
 
chshrmcAuthor Commented:
I should also state that this is my first ever attempt at a cron job

myhost:~ # ls -l /
.... lots of other junk
drwxr-xr-x   5 root root    120 May 18 11:11 path
.... more junk

myhost:~ # ls -l /path/
drwxr-xr-x  21 root root 576 May 24 16:51 To

myhost:~ # ls -l /path/To
-rwxr--r--   1 root root 2457 May 18 11:01 my-script.php

myhost:~ # ls -l /path/To/my-script.php
-rwxr--r--  1 root root 2457 May 18 11:01 /path/To/my-script.php
0
 
ahoffmannCommented:
is it a mounted filesystem? check with
  cd /path/To && df .
0
 
chshrmcAuthor Commented:
myhost:~ # cd /path/To && df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda1             38706460   2727728  35978732   8% /
tmpfs                   127564         8    127556   1% /dev/shm
0
 
ahoffmannCommented:
annd all this applies to the file/path $dir/$name you try to open with fopen() ?
0
 
chshrmcAuthor Commented:
yes.... that is correct.... could the problem perhaps be with some kind of settings within Cron, I notice when I receive the email I get some the following messages at the top.
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

is all of that correct?
0
 
ahoffmannCommented:
that's correct (if you intend to run that cron as user root)
Again: is $dir/$name on a mounted filesystem, or is any part or this full path a symbolic link?
0
 
chshrmcAuthor Commented:
the $dir/$name is on the same filesystem as everything else and is not any part sysmbolic link
0
 
chshrmcAuthor Commented:
This issue is still occuring and nothing so far has seemed to resolve it.  I'm going to increase the points to 500!!!
0
 
chshrmcAuthor Commented:
Here are a few findings.... I still think this has to do with the rights and the user that the cron daemon thinks is running the program... so I did the following
crotab -u root -e
and edited the crotab file and ran
17 16 * * * id -un
This was to see if it would register a user running the cron job.  I got the following response :
id: : No such user
is this normal?
0
 
2266180Commented:
try using
17 16 * * * id
that will give more info
0
 
chshrmcAuthor Commented:
I receiveved the following
id: : No such user
I'm not sure if that is what its supposed to do or not though, but if it is running w/o a user, that could be a problem.
0
 
chshrmcAuthor Commented:
I also checked the /var/log/messages file and found an entry for
/USR/SBIN/CRON[29682]: (root) CMD (id ^M) at the time of the cron job

and checked the back log and found
/USR/SBIN/CRON[24343]: (root) CMD (/usr/bin/php /path/To/my-script.php^M)

is the ^M normal?
0
 
2266180Commented:
dunno exactly what ^M is for. probably some terminator.
it's pretty weird what is happening to you though. try this setup:

crontab -u root -e
delete everything (back it up if necesssary)
put
0,10,20,30,40,50 * * * * /root/run.check
(tgis is 10 min period. you can decrease it if you want, depends on how fast you are checking logs and such)
where run.check is:
#! /bin/sh
  echo ""
  echo "Some random message here issued on:"
  date
  echo ""
exit 0

and
-rwxrw-r--    1 some_user   some_user        334 Apr 18 22:49 /root/run.check

where some_user can be anything (on my system, it's not even equal to root :D (though it's in root's folder and run from root's crontab)
HOWEVER, I logged in with some_user and THEN "su -" and THEN crontab -u root -e
this might be nothing... but it might be the thing.

I of course have the localmachine set up for emailing with both some_user@mydomain and root@mydomain (mail is comming on root@mydomain though) and evironment variables USER and USERNAME are both set to root
0
 
chshrmcAuthor Commented:
This still doesn't appear to work.... I tried this both in the /root directory and the /tmp directory and got the following response:

/bin/sh: line 1: /root/run.check: No such file or directory

I'm just not sure why it can't find files
0
 
2266180Commented:
that is too weird. I suggest creating another question with title: "Pointer: crontab issue" (or something similar, make sure pointer is the first workd, asign 20 points to it (minimum) and put a link to this question in it; so that other people will look to this question.
sorry I cannot be of more help.
0
 
chshrmcAuthor Commented:
Ok, one last comment then, I have another machine setup that is very similar to this, I can run the cron jobs from it, so this seems like it would have to be something with cron itself
0
 
2266180Commented:
hm ... well, you could try to reinstall it from cd's or rpm's and maybe see who is starting it.
maybe compare startup configuration files. hard to say what could cause this behaviour
0
 
chshrmcAuthor Commented:
after i reinstalled cron http://www.experts-exchange.com/Operating_Systems/Linux/Linux_Administration/acceptAnswer.jsp?aid=16905216
Acceptand took some kind of update from SuSE it worked.  Thank you very much for your assistance
0
 
2266180Commented:
glad it got solved :)
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 19
  • 11
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now