weird issues with "at" command
iondelafukrie
the at binary at the exact same size so they are identical.On one
system if I create a file called at.cmd with the following contents:
export LIBPATH=/usr/lib:/usr/ibmcxx/lib:/usr/local/lib:/opt/IBM/db2/
V9.5/lib64:.:/home/bncprod/lib:/cb/dev/rel4.8/bl1491/lib
echo test >>$HOME/cblog.test 2>&1
My test file is created and "test" is inserted into the file. On the
other system, the job fails *unless* I chmod +x the actual at.cmd
file. On the first system, the permissions are simply 644 and at.cmd
is not executable.
/var/adm/cron/log shows "ian : CMD ( ian.1260994697.a ) : PID
( 524480 ) : Wed Dec 16 15:18:17 2009
Cron Job with pid: 524480 Failed
/var/spool/mail/root contains:
ksh[3]: at.cmd: 0403-006 Execute permission denied.
This is messing up some jobs that our application is trying to
run. . . any ideas wy this might e happening?
iondelafukrie
I forgot to say I execute at via the command line in this example "at
now at.cmd"
Henry
any difference in the /etc/profile or /etc/environment files of the 2
LPAR's or the /etc/passwd ?
are you in the same directory on both LPARs and what are the file
permissions there ?
No ACL's ?
you could insert a
ps aexwww
to help debugging
can we have an ls -l from both LPAR's too and echo of $PATH
iondelafukrie
There are some differences in the profiles of the users. . . nothing
that I would have though would make a difference but you never know.
I'm going to create another user and make it exactly the same as the
user that works. I will update after a test.
iondelafukrie
I've made the .profiles exactly the same (except editing for
hostname). Umasks are the same, ulimits are the same. I've done an
"env" on both systems and compared and except for hostname and
username the environment variables are the same. Both tests are
executed in /tmp/test with the permissions of the directory as below
(one user is abccont, and the other abcprod.
abcprod_[/tmp/test]ls -l /tmp/test
total 8
-rw-r--r-- 1 abcprod staff 158 Dec 18 11:21 at.cmd
ancprod_[/tmp/test]ls -ld /tmp/test
drwxr-xr-x 2 abcprod staff 256 Dec 18 11:21 /tmp/test
One difference I did note was that the following:
AUDIT classes
[]
+
TRUSTED
PATH?
+
PRIMARY authentication method
[]
SECONDARY authentication method []
Is all blank in SMIT for abcprod but for abctest (the one that fails)
it is:
I just don't get how "at" can fail on one but not the other?
iondelafukrie
tested again with those settings the same as well with no difference.
Gary R. Hook
>>
>>> On Dec 16, 3:26 pm, iondelafukrie <ian.ross.guth...@gmail.com> wrote:
>>>> I've got two AIX systems, both at 6100-03-01-0921. Both systems have
>>>> the at binary at the exact same size so they are identical.On one
>>>> system if I create a file called at.cmd with the following contents:
>>>> export LIBPATH=/usr/lib:/usr/ibmcxx/lib:/usr/local/lib:/opt/IBM/db2/
>>>> V9.5/lib64:.:/home/bncprod/lib:/cb/dev/rel4.8/bl1491/lib
>>>> echo test >>$HOME/cblog.test 2>&1
>>>> My test file is created and "test" is inserted into the file. On the
>>>> other system, the job fails *unless* I chmod +x the actual at.cmd
>>>> file. On the first system, the permissions are simply 644 and at.cmd
>>>> is not executable.
>>>> /var/adm/cron/log shows "ian : CMD ( ian.1260994697.a ) : PID
>>>> ( 524480 ) : Wed Dec 16 15:18:17 2009
>>>> Cron Job with pid: 524480 Failed
>>>> /var/spool/mail/root contains:
>>>> ksh[3]: at.cmd: 0403-006 Execute permission denied.
>>>> This is messing up some jobs that our application is trying to
>>>> run. . . any ideas wy this might e happening?
>>> I forgot to say I execute at via the command line in this example "at
>>> now at.cmd"
Umask should never allow you to automatically make a shell script
executable. While I'm not sure where "at.cmd" comes into play,
because your explanation appears incomplete, it's safe to say that if
you wish to build and execute a shell script, whether via at or
interactively, you're going to have to explicitly chmod +x at some
point.
If I'm missing the point, please more clearly describe your steps
and explain where at.com is involved.
Uwe Auer
Hi,
more strange is - from man page - it shouldn't work in both cases since
"at" reads from standard input only, unless you specify -f option.
From man page:
To Schedule Jobs to Run at a Later Time
at [ -c | -k | -s | -q Queue ] [ -m ] [ -f File ] { -t Date |Time [ Day
] [ Increment ] }
...
Description
The at command reads from standard input the names of commands to be run
Furthermore noticeable is that your /var/adm/cron/log shows
"ian.1260994697.a" meaning that the job has been submitted by user "ian"
but failling mail goes to /var/spool/mail/root instead of
/var/spool/mail/ian.
Anyway, on my systems it does work - as execpected - with "+x" only
(I've got the same oslevel).
Regards,
Uwe Auer