This content has been marked as final. Show 3 replies
I am a little confused. "umask" is only used when you are creating the file. If you are using utl_file to create the file then extjob (or the scheduler) is not being used at all.
It could also be that nobody is running into some other error in the script which throws this error. Have you checked dba_scheduler_job_run_details for the full error message ? Does your script have full paths to all binaries and are all binaries executable by nobody ?
Sorry for the later reply. I went to france for my short vacation.
You are right. If I only use utl_file, there is nothing to do with extjob. But if I wanna run the extjob which the content is in the file generated by utl_file, I can't do it. Because the *.sh file is not allowed to read by oracle user (umask 0027) while the owner and group is nobody. That's why I wanna the extjob umask can be set to 0022. I hope I make the story clear now.
I believe that utl_file creates files with the umask value of the oracle user(027 in your case). You can check the os documentation to change the umask value of an os user.
The switching of umask to 022 in the foreground is in fact a Scheduler bug which has been fixed in 18.104.22.168 where using run_job to run an external job would cause the umask value of the foreground to change (so utl_file would see a wrong umask when run in the foreground).
This is not something that should be happening and not something you should rely on.
Changing the umask for extjob wouldn't help since the umask is only in effect when the file is created. The umask for an external job should be the umask of the user the job is running as.
Hope this helps,