cannot run jobs in AIX-Unix Production environment, same account works in test environment
I am able to run jobs in a test machine but not on Prod, same user id (different machines)
I reviewed the profile for each, only see one difference but that might be the machines.
When I run the job, everything looks normal but the job stops with this message:
time_start=11/04/11 15:59:13
+ mv /slice6/imedw/medpartd/pde
override mode 640 on /slice6/imedw/medpartd/pde
ksh: y: not found
[1] + Stopped (SIGTTIN) ./medpartd_pde_load.ksh 2010 194 &
When I check on the jobs running, I see this below /**** open jobs for user ********/
When I kill the jobs, I see
[1] + Terminated ./pde_load_multiple_files_
I've included the two profiles below,
So on the Prod box, when I run jobs through the scheduler, it works. But when I run the job manually, I get the errors above. Here's my command (which works fine on test box and I run jobs all the time).
I also have another user id on the Prod box and I can run jobs fine there manually.
I reviewed the profile for each, only see one difference but that might be the machines.
When I run the job, everything looks normal but the job stops with this message:
time_start=11/04/11 15:59:13
+ mv /slice6/imedw/medpartd/pde
override mode 640 on /slice6/imedw/medpartd/pde
ksh: y: not found
[1] + Stopped (SIGTTIN) ./medpartd_pde_load.ksh 2010 194 &
When I check on the jobs running, I see this below /**** open jobs for user ********/
When I kill the jobs, I see
[1] + Terminated ./pde_load_multiple_files_
I've included the two profiles below,
So on the Prod box, when I run jobs through the scheduler, it works. But when I run the job manually, I get the errors above. Here's my command (which works fine on test box and I run jobs all the time).
I also have another user id on the Prod box and I can run jobs fine there manually.
/************* open jobs for user *************/
[/slice6/imedw/medpartd/code_non_compile] psf
immedpd 626918 1552400 0 13:49:20 pts/0 0:00 /usr/bin/sh ./pde_load_multiple_files_parameter.ksh 25 30 2010 194
immedpd 675996 626918 0 13:49:20 pts/0 0:00 /usr/bin/sh /slice6/imedw/medpartd/code_non_compile/medpartd_pde_load.ksh 2010 19
4
immedpd 1552400 1069436 0 13:47:24 pts/0 0:00 -ksh
immedpd 1593556 675996 0 13:49:20 pts/0 0:00 mv /slice6/imedw/medpartd/pde/data_land/pde_argus.dat /slice6/imedw/medpartd/pde/
pde_argus.dat
/**************** profile on test box, med_d user (can run jobs manually) *************/
# Set up the shell environment:
set -u
trap "echo 'logout'" 0
# Set up the shell variables:
EDITOR=vi
export EDITOR
umask 002
ORACLE_BASE=/u01/app/oracle
export ORACLE_BASE
ORACLE_HOME=/u01/app/oracle/product/10.2.0_db
export ORACLE_HOME
ORACLE_SID=edwdev02
export ORACLE_SID
PATH=$PATH:$ORACLE_HOME/bin:/opt/binutils/bin:/opt/gcc/bin:/usr/local/bin:.
export PATH
alias test='ORACLE_SID=edwtst05'; export ORACLE_SID
alias db='echo $ORACLE_SID'
export PS1="["'${PWD}'"] $ "
alias sql='sqlplus'
alias tnc='cd /slice6/imedw/medpartd/test_non_compile'
alias tc='cd /slice6/imedw/medpartd/test_compile'
alias dnc='cd /slice6/imedw/medpartd/dev_non_compile'
/**************** profile on prod box, med_d user (cannot run jobs manually) *************/
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:/usr/java131/bin:.
export PATH
if [ -s "$MAIL" ] # This is at Shell startup. In normal
then echo "$MAILMSG" # operation, the Shell checks
fi # periodically.
# Set up the shell variables:
EDITOR=vi
export EDITOR
export ORACLE_HOME=/u01/app/oracle/product/10.2.0_db
export PATH=/slice6/imedw/medpartd/code_non_compile:/slice6/imedw/medpartd/code_compile:/usr/local/bin:/home/imedw:$ORACLE_HOME/bin:$PATH
export ORACLE_SID=edwprd05
#umask 033
umask 003
export PS1="["'${PWD}'"] "
unalias rm
alias sql='sqlplus'
alias cc='cd /slice6/imedw/medpartd/code_compile'
/**************** profile on prod box, imedw user (can run jobs manually) *************/
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:/usr/java131/bin:.
export PATH
if [ -s "$MAIL" ] # This is at Shell startup. In normal
then echo "$MAILMSG" # operation, the Shell checks
fi # periodically.
# Set up the shell variables:
EDITOR=vi
export EDITOR
export ORACLE_HOME=/u01/app/oracle/product/10.2.0_db
export PATH=/slice6/imedw/code_non_compile:/slice6/imedw/code_compile:/usr/local/bin:/home/imedw:$ORACLE_HOME/bin:$PATH
export ORACLE_SID=edwprd02
#umask 033
umask 003
export PS1="["'${PWD}'"] "
unalias rm
set -o vi
####stty erase ^h
####stty erase ^?
alias w='w'
alias psf='ps -ef | grep imedw'
I don't know that the two environment files matter - it looks like the permissions for /slice6/imedw/medpartd/pde
BTW, the fact that when you hit 'y' to confirm and get "ksh: y not found" tells me the script has already exited at that point, and just didn't give the CR/LF needed to return you to the prompt.
BTW, the fact that when you hit 'y' to confirm and get "ksh: y not found" tells me the script has already exited at that point, and just didn't give the CR/LF needed to return you to the prompt.
same result . . . I even changed the permissions as the permissions weren't set right, and the file owner was different from my account.
- I also created the file as the account owner, same result.
so I got the same results, see code section.
I don't think it's file permissions, as this is actually a long-standing issue. It's something with the account not being able to do something.
However, when the jobs are run through the scheduler, they work, even though the scheduler uses the same account that I am trying to run them manually.
be back online late tonight, thanks.
-------------------------
the files on the machine where I can't run were owned by me (bpeck), but the superuser is "my_superuser_acct".
so I changed them all to 777, so they look like this now:
-rwxrwxrwx 1 bpeck users 8512722 Nov 03 15:57 pr_dat_0467.txt
- I also created the file as the account owner, same result.
so I got the same results, see code section.
I don't think it's file permissions, as this is actually a long-standing issue. It's something with the account not being able to do something.
However, when the jobs are run through the scheduler, they work, even though the scheduler uses the same account that I am trying to run them manually.
be back online late tonight, thanks.
-------------------------
the files on the machine where I can't run were owned by me (bpeck), but the superuser is "my_superuser_acct".
so I changed them all to 777, so they look like this now:
-rwxrwxrwx 1 bpeck users 8512722 Nov 03 15:57 pr_dat_0467.txt
time_start=11/04/11 18:39:10
+ mv /slice6/imedw/medpartd/pde/data_land/pde_argus.dat /slice6/imedw/medpartd/pde/pde_argus.dat
override mode 640 on /slice6/imedw/medpartd/pde/pde_argus.dat? y
ksh: y: not found
[1] + Stopped (SIGTTIN) ./medpartd_pde_load.ksh 2010 194 &
Well, the accounts aren't able to do things based on the permissions of the files/folders they interact with. So I would compare the permissions all the way upwards on each folder, so pde, medpartd, imedw, and even slice6. Better yet, it's complaining about something with a specific mode, so why not go into /slice6 and do "find . -type d -mode 0640" and hopefully it's not too long of a list. I think when you find that directory, it's permissions will differ from that of the other server.
You can change your txt file back to 0644 or whatever it was - 777 is never a good idea, and besides, no matter what you set file perms to, they will never override that of the directory they're in.
You can change your txt file back to 0644 or whatever it was - 777 is never a good idea, and besides, no matter what you set file perms to, they will never override that of the directory they're in.
I ran this: find . -type d -perm 0640
and got this:
find: cannot chdir to </slice6/imedw/medpartd/en
find: cannot chdir to </slice6/mhcc/code_non_com
find: cannot chdir to </slice6/stars/code_non_co
find: cannot chdir to </slice6/mhcc_pcmh/code_no
find: cannot chdir to </slice6/Member Health Statements> : Permission denied
find: cannot chdir to </slice6/silverlink/code_n
So only the first folder is in the "medpartd" path but it's not the "pde" folder I am using.
I still am confused as to folder / file permission, because when the scheduler job runs (CA-7), the jobs work, and they're run in CA-7 with the same id as I am trying to run the job manually.
So I can run this job successfully from CA-7:
/slice6/imedw/medpartd/job
but I get the error when running this job: ./claims_load.ksh
from /slice6/imedw/medpartd/job
and got this:
find: cannot chdir to </slice6/imedw/medpartd/en
find: cannot chdir to </slice6/mhcc/code_non_com
find: cannot chdir to </slice6/stars/code_non_co
find: cannot chdir to </slice6/mhcc_pcmh/code_no
find: cannot chdir to </slice6/Member Health Statements> : Permission denied
find: cannot chdir to </slice6/silverlink/code_n
So only the first folder is in the "medpartd" path but it's not the "pde" folder I am using.
I still am confused as to folder / file permission, because when the scheduler job runs (CA-7), the jobs work, and they're run in CA-7 with the same id as I am trying to run the job manually.
So I can run this job successfully from CA-7:
/slice6/imedw/medpartd/job
but I get the error when running this job: ./claims_load.ksh
from /slice6/imedw/medpartd/job
Well, I made it through the crisis by running the jobs through the Scheduler, CA-7.
There is one slight security difference between the two accounts:
When I log on to the account where I can't run jobs manually, I get this:
[KRB5Afiles]: You entered an invalid login name or password.
It has something to do with various layers of security on the machine. When I log on to the same machine with the other account where I CAN run jobs manually, it's a clean login.
So I will try a few other people around here and see what they say.
There is one slight security difference between the two accounts:
When I log on to the account where I can't run jobs manually, I get this:
[KRB5Afiles]: You entered an invalid login name or password.
It has something to do with various layers of security on the machine. When I log on to the same machine with the other account where I CAN run jobs manually, it's a clean login.
So I will try a few other people around here and see what they say.
The scheduler is probably running as root, no?
If you su root and run the job manually, do you still get permission errors?
If you su root and run the job manually, do you still get permission errors?
I'm not sure what that means, but if you just type "su", it should prompt you for the root password. Enter the root password and then you will "become" root. Then run your script.
One other thing to consider is the default shell of the two accounts in the /etc/passwd file. That can cause the two different accounts to run the same things and get an error with one of them.
The workaround is to set them both the same, the fix is to use #! /path/to/shell as the first line of the script. For example, if it is supposed to run as KSH you might need #! /usr/bin/ksh.
The workaround is to set them both the same, the fix is to use #! /path/to/shell as the first line of the script. For example, if it is supposed to run as KSH you might need #! /usr/bin/ksh.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial