This content has been marked as final. Show 17 replies
If you do
select * from all_scheduler_job_run_details;
you should see more info about the error (messages from standard error).
The problem here is probably that "php" is not being found. When Oracle executes an external job all environment variables are cleared out, including $PATH. So you probably need to use the full path to php e.g. "/usr/bin/php"
Did you try with a simple shell program without psp.
For example, create this file /tmp/test.sh with this two lines :
ls > /tmp/test.log
Then create the job :
And verify if everything is fine with :
select log_id, log_date, job_name, status, error#, additional_info
where job_name ='TEST';
Hi. I'm having a similar problem that I'm looking into. I'm guessing it is due to the following that I found in the 10gR2 admin guide (chapter 27 Using the Scheduler) :
"All external jobs run as a low-privileged guest user, as has been determined by the database administrator while configuring external job support. Because the executable will be run as a low-privileged guest account, you should verify that it has access to necessary files and resources. Most, but not all, platforms support external jobs. For platforms that do not support external jobs, creating or setting the attribute of a job or a program to type EXECUTABLE returns an error."
I am getting the same error
CREATE OR REPLACE procedure abc_1 as
CREATE OR REPLACE procedure abc_2 as
SQL> exec abc_1
PL/SQL procedure successfully completed.
SQL> exec abc_2
BEGIN abc_2; END;
ERROR at line 1:
ORA-27369: job of type EXECUTABLE failed with exit code: Permission denied
ORA-06512: at "SYS.DBMS_ISCHED", line 150
ORA-06512: at "SYS.DBMS_SCHEDULER", line 441
ORA-06512: at "SYS.ABC_2", line 6
ORA-06512: at line 1
any one got the solution.pl pass it.
If rdbms/admin/externaljob.ora exists then external jobs run as the user and group specified in this file.
If it does not exist then external jobs run as the owner of bin/extjob which should be nobody by default.
Because external jobs run as a lowly privileged user (nobody) by default, you need to make sure that this user can execute your script. Things to check for include
1) Use full paths to all binaries or scripts
2) Make sure all scripts start with #!/bin/sh or another interpreter
3) Make sure all scripts have the executable bit set and are executable by the user that external jobs run as.
4) Make sure that all required enviropnment variables are set. External jobs by default do not have any environment variables set. For example, for an oracle import or export or sqlloader script you may need to set oracle_home, oracle_sid, ld_library_path and path environment variables in your script or source the required Oracle environment script.
Hope this helps,
extproc is a different component (calling external C procedures from PL/SQL) . It is completely separate from the Scheduler .
To switch the user that all external Scheduler jobs on UNIX run as you need to do one of two things depending on your release.
- in release 10.2.0.2 or prior releases (where there is no rdbms/admin/externaljob.ora) you need to change the owner of the extjob executable (who should be nobody by default) .
- in 10.2.0.3 you just need to edit the file rdbms/admin/externaljob.ora to switch the run-user to the user that all jobs should run as
On Windows you need to change the user that the external jobs extjob Windows service runs as.
Note that changing this user allows all database users who can run external jobs to execute code as this user. If you are using 10.2, you should carefully restrict the CREATE EXTERNAL JOB system privilege if you are doing this. If you are using 10.1, there is no CREATE EXTERNAL JOB system privilege (just the regular CREATE JOB privilege) but you should be aware of the security impact of this move.
Hope this helps,
Yes, you are right Ravi, a slip of the keyboard. Was just involved debugging an extproc ...
I think the advice - seen from security - is to use at least 10.2.0.2 (in which the extjob.ora is introduced). The other releases are not secure because they rely on setuid on extjob.
Ofcourse this all depends on the need to run external jobs and who is to be allowed to create and execute them.
I've checked those readme-es for 10.2.0.1. It seems that for that version there is only small note about creating user nobody and providing for him rights to the file extjob. There is no word about configuration file externaljob.ora in ORACLE_HOME/rdbms/admin - may be that is the difference between 10.2.0.1 and 10.2.0.3
Anyway thanks for Your kind answer :-)