QUESTION:
My customer has a 7135 hooked to one RISC System/6000. We have
REACT/READI installed.
We find that we have little control over the entry in
root's crontab for running the "apcheckall" script. It starts out
like this in /var/spool/cron/crontabs/root:
0 2 * * * "/bin/su root -c /etc/array/apcheckall >/dev/null 2>&"
We notice three things "wrong".
1) we do not understand why this would be written as "su root -c"
instead of just putting the apcheckall command in alone.
2) this command, run from csh or ksh, produces an immediate error
message of "ambiguous output redirect". So it is in error, though
we can't figure out WHY. Is this a bug?
3) if we comment out this line in cron, or change it, the change is
"erased" by the next day. I have found that this cron entry is
controlled in /etc/array/startup_amdapc.boot, a.k.a.
/usr/lpp/scarray/startup_amdapc, and I can edit this script
(to read as follows on lines 40-42:
then
/bin/echo 0 2 '* * * '"$APCKALL " >> $TMP
fi )
and this keeps the cron entry unchanging. But I can't figure out
WHAT PROGRAM IS CALLING startup_amdapc.boot or startup_amdapc each
night. Can you tell me if my NEW syntax for the command for cron
in startup_amdapc.boot is OK, and can you tell me what command
is calling startup_amdapc.boot?
I'd call all this into defect support, but I already had 1x013 b137
and the progress left me less than happy with their current
knowledge of the software side of this product.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
Last night the script ran, but we got mail back to root that says
the following (summary):
Checking or repairing of disk array parity errors on hdisk3
failed due to the following error(s):
Beginning parity verification of disk blocks numbered 0-15708159 (decima
Verifying blocks 000000-009999 (decimal) ...
Checking or repairing of disk array parity errors on hdisk4
failed due to the following error(s):
Beginning parity verification of disk blocks numbered 0-15708159 (dec
Checking parity on hdisk3
hdisk3 checked OK.
Checking parity on hdisk4
hdisk4 checked OK.
---------- ---------- ---------- --------- ---------- ----------
A: I do not believe any of this is a defect but I don't have a good
explanation of why you get the "ambiguous output redirect" message
when running from the Korn shell.
This message is a know problem when running Korn shell scripts from a
C shell. The output redirection syntax in the Korn shell script is
not compatible with the C shell.
I have run this command from the command line from a Korn shell and
do not get this message. You might check the default shell for root
and make sure it is the Korn shell or make sure your ksh has not been
eliminated by some user modification/symbolic link.
I don't know why the developer decided to use the preceding su to
root in the crontab file. The idea would be for the script to run
with root authority and then return to the calling shell but since
cron will run it with root authority is seems like an unnecessary
addition. I see no problem in your modification that removes it, but
since it doesn't hurt anything I see no reason to remove it either.
The reason the crontab keeps coming back is that the software installs
a phase 2 config rule in the Config_Rules ODM data base. This means
that every time the system is rebooted or cfgmgr is run, this config
method takes the existing root crontab file and extracts any previous
apcheckall lines and then re-adds the line again, as you found in the
startup_amdapc script. This script is run whenever cfgmgr runs
phase 2 config methods.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q658022 CRBTV
Additional search words:
AMDAPC.BOOT APCHECKALL BEHAVIOR CRBTV CRONTAB ENTRY IX MANAGEMENT
MAY94 OP OZNEW QUESTION REACT READI RISCMGMT RISCSYSTEM SOFTWARE
STARTUP STRANGE SYNTAX SYS SYSTEM 7135
WWQA: ITEM: RTA000041782 ITEM: RTA000041782
Dated: 03/1996 Category: RISCMGMT
This HTML file was generated 99/06/24~12:43:16
Comments or suggestions?
Contact us