error mails from cc-invagent
On many of my solaris 10 boxes, the cron job running cc-invagent which I believe is part of update connection is producing error messages as follows
Your "cron" job on messaging1
/usr/lib/cc-cfw/platform/invagent/bin/cc-invagent
produced the following output:
touch: @LOCK_DIR@/lock.14316 cannot create
@LOCK_DIR@: No such file or directory
The boxes are up to date with their patches.
Are other people seeing this.
Any suggestions.
# 1
Hello Robert,
The cc-invagent script is generated using perl from a skeleton
file by the /usr/lib/cc-cfw/platform/invagent/enable script. This
also adds the crontab entry after the cc-invagent script is created.
The @LOCK_DIR@ parameter should normally be set to the
/usr/lib/cc-cfw/platform/invagent/lock directory and the @JAVA_HOME@
parameter should also be set depnding on the installed Java.
Regards,
# 2
Well, running the enable script manually appears to do the right thing.
However, this is happening on any box we install solaris10 on.
I could add a manual invocation of enable to our new box configuration scripts.
But we shouldnt have to.
I would prefer to figure out why its not working correctly in the first place.
How does that enable script normally get invoked.
I assume it being invoked, just not working correctly since the cron job does get installed.
# 3
I'm not 100% certain where the enable script is invokled from so i've asked our developers to clarify as well as provide some input as to possible reasons why only part of the script would fail and the rest doesnt (without producing any errors)
Once we get an update we'll post it here.
# 4
When I manually run the script I get the following output
uatu# sh /usr/lib/cc-cfw/platform/invagent/enable
Updating crontab for root.
The property file /var/cc-ccr/platform.properties does not exist, so creating it.
Adding the key cns.service.platform.status.default to CCR
Adding the key cns.service.platform.status.secret to CCR
Adding the key cns.component.invagent.status.default to CCR
Adding the key cns.component.invagent.status.secret to CCR
/usr/lib/cc-cfw/platform/invagent/etc/cc-invagent
/usr/lib/cc-cfw/platform/invagent/etc/runlevel
If I run it again I get this output
uatu# sh /usr/lib/cc-cfw/platform/invagent/enable
WARNING: invagent already enabled. Not making any changes to the crontab
/usr/lib/cc-cfw/platform/invagent/etc/cc-invagent
/usr/lib/cc-cfw/platform/invagent/etc/runlevel
ln: cannot create /etc/init.d/cc-invagent: File exists
The fact that the output is so different the second tine implies that maybe its never been run?
# 5
Robert,We've had an update from the developers who tell us that patch 121081-03 breaks ccinvagent. It steps on the file about which cron is complaining. Patch 121081-04 undoes the damage.The work-a-round is to manually enable cc-invagent as you have previously done.
# 6
Ok, that appears to fix it for the machines that were generating the errors.
But looking into this issue more closely, I have realised that only machines that were jumpstarted with Solaris 10 03/05 actually appear to have cc-invagent enabled.
On machines that were jumpstarted with Solaris 10 01/06, it just hasnt been initialised.
Comparing the crontabs for machines between the 2 versions I also notice that the Solaris 10 1/06 machines are also missing the following entries
29 * * * * /usr/lib/patch/swupas > /dev/null 2>&1
14 3 * * * /usr/lib/patch/swupAuto > /dev/null 2>&1
Which presumably are part of update connection.
So why isnt this stuff being initialised in Solaris 10 1/06?
# 7
Actually it appears that the difference is nothing to do with Solaris 10 03/05 versus Solaris 10 01/06.
The earlier systems were manually registered with Update Connection.
Since we rolled out our a local patch proxy, I havent been bothering to register machines, I just point them at the patch proxy.
Are we missing out on any functionality by not registering them (apart from the gui, and the web interface).
We normally only use the smpatch cli interface.
# 8
The only feature you wont have in the setup you describe is the web interface.
