unix`at`来自php脚本，可在Shell中工作，但不能从Web中工作

Question

I am having trouble executing a unix at job command from a php webscript. the php with the at job looks like this:

$output=exec('echo "/usr/bin/perl /home/dir/test.pl" | /usr/bin/at now +1minute')

This will work fine from the shell command prompt. I can execute the php script, run atq to see that job has been set and the job belongs to root. Then wait and confirm that the test.pl script has run. The test.pl script performs a simple update to a database which I can check to confirm everything has worked.

When I execute the php script from the web, go back to my shell and run atq again. I can see that the job has been placed, this time the job belongs to apache, so everything seems fine. But after waiting for the scheduled time, the test.pl script does not execute which I can confirm after seeing the update to the db has not worked.

I belive this must be a permissions issue, but I am not sure. I tried giving /home/dir and the test.pl script ownerships to apache but this still does not work. I tried createing a symlink to /home/dir in the webroot folder but this did not seem to help either. I do not know apache permissions to well so I could be overlooking something.

here is the directory and test.pl ls -l ouput

/home/dir
drwxrwxr-x 2 apache apache

test.pl
-rwxr-xr-x 1 apache apache

Thanks for any help on this one.

Answer 1

If the job is being enqueued then we can discount the possibility that the apache uid is denied access to 'at'.

This then implies that the job is probably failing to execute (how do you know it is failing to run?)

Since you have root access, the next step would be to look at the mail file for the apache uid - or determine where mail for this uid is sent and look there: from the man page :

The user will be mailed standard error and standard output from his commands, if any. Mail will be sent using the command /usr/sbin/sendmail

(If you don't find anything there, then you might want to try something like pwd | mail -s test apache or running at with -m to check that mail does get handled as it should)

Normally a daemon owner won't have any shell configured - did you set $SHELL before invoking at? (if this is the case and the mail is getting sent then there will be a corresponding error waiting to be read).

You've checked the permissions on the test.pl file and that does not appear to be the issue (assuming fACLs or SELinux restrictions are not being applied). Have you checked the permissions of the perl executable? Could test.pl be attempting to access other files which it might have permissions on?