I was encountered another strange problem.
I have a stored procedure which will first create a sh script in the system and execute the script later. If I call the stored procedure from the foreground, everything works fine while run it as backgound, it fails. When I check "all_scheduler_job_run_details" view, I found "perssion denied". I found the sh script is with "-rw-r----" permission and the owner of the sh script is oracle user which is logical because I use utl_file package to create the file. But the extjob runner is nobody which is in "other" group and obviously he don't has enough privilege on the sh script. I tried umask on the background, it gives me "0027" and on the foreground, it is "0022".
I know that I can create the file using the command line as well so that the owner will be nobody as well.
My question is that how could I change the umask to "0022" when I run the extjob.
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.