Systems not checking in
Hi,
I'm having a problem with one of my systems not checking in to Update Connection. I have registered the system using sconadm. Registration completes fine and the system shows up as being available for updates. After two hours however the system then appears to fail to check in again and displays as "Not checked in" in the web interface. The last check-in date is displayed as the time that the system was originally registered.
Any ideas as to how I can go about fixing this? I've tried deleting the system, waiting 24 hours and then re-registering but this doesn't seem to help.
Thanks in advance for any suggestions.
Message was edited by:
kjdavidson
Fixed typo
[716 byte] By [
kjdavidson] at [2007-11-26 8:22:07]
# 1
Could you check the last check-in time on the host with:# /usr/lib/cc-ccr/bin/ccr -g cns.swup.lastCheckin(multiply by 60 to get Unix time)Please also check that the crontab entries for swup are present with:# crontab -l | grep swup
# 2
Thanks for the reply.
Here's the command output:-
bash-3.00# /usr/lib/cc-ccr/bin/ccr -g cns.swup.lastCheckin
19194107
bash-3.00# crontab -l|grep swup
1 * * * * /usr/lib/patch/swupas > /dev/null 2>&1
48 0 * * * /usr/lib/patch/swupAuto > /dev/null 2>&1
bash-3.00#
# 3
Can you check the contents of the following log files for any errors - /var/log/swupas/swupas.log /var/log/swupas/swupas.error.log
# 4
No errors appear in either of these log files.
/var/log/swupas/swupas.error.log
is empty
/var/log/swupas/swupas.log
has the following
Swup Agent run: Mon Jul 3 07:01:00 BST 2006
** DEBUG ON **
Attempt to get exclusive lock: 1
We have the lock!
prepare to register with Transport
Registration complete
Sleeping 90 secs...
OK, WE'RE AWAKE AGAIN!...
Updated last checkin time in CCR: 19198427
Number of swup server cmds to be executed: 0
smpatch collection name:current
old cache age (min): 479
need an analysis update: false
Exiting for now...
Swup Agent finish: Mon Jul 3 07:02:33 BST 2006
# 5
Hi,When you registered the system , did you select "Managed" ? The check-in field pertains only to those hosts that may be remotely managed from the portal.Additionally, if you have a Sun Update Connection Proxy, client will check-in to that machine.
# 6
The systems were registered using sconadm from the command line.
sconadm register -a -r /var/sadm/patch/sconadm.register -e softwareUpdate
The contents of the registration file are
userName=<myUsername>
password=<myPassword>
hostName=<myHostname>
subscriptionKey=<mySubscriptionKey>
portalEnabled=false
proxyHostName=
proxyPort=
proxyUserName=
proxyPassword=
I've used the same file (with a different hostname value) for two different hosts, one of which registers and then regularly checks in no problem and the other which registers but then fails to check in.
# 7
I am having a similar problem, however I have errors in my log:
Swup Agent run: Mon Jul 3 12:17:00 CDT 2006
** DEBUG ON **
Attempt to get exclusive lock: 1
We have the lock!
prepare to register with Transport
Error: unable to register with Transport
com.sun.cc.transport.client.TransportAdapterException: proxy communication failure
at com.sun.cc.transport.client.TransportAdapter.register(TransportAdapter.java:474 )
at com.sun.cc.transport.client.TransportAdapter.<init>(TransportAdapter.java :305)
at com.sun.swup.client.agent.SwupAgent.main(SwupAgent.java:337)
Swup Agent finish: Mon Jul 3 12:19:30 CDT 2006
# 8
bcummings : Is the transport running? (ps -ef | grep cct)kjdavidson : Can ypou verify if the inventory agent entry id present in crontab and try running it manually to ensure that it completes successfully (crontab -l | grep invagent)
# 9
OK, I think I've found the problem. I noticed I had a lot of these entries in /var/adm/messages
CNS Transport[1691]: [ID 617356 daemon.error] Could not send message from queue: /var/tmp/cc-transport/
CCTQueueStore/store/queues/REGISTRATION/registration
A quick search turned up the following thread
http://forum.sun.com/jive/thread.jspa?threadID=92320&tstart=15
which seemed to give the solution
1. Apply patch 122231-01
2. Run /usr/lib/cc-cfw/platform/transport/bin/cctrunner -p
to verifiy the connection.
After doing these all the temporary registration files in /var/tmp/cc-transport/CCTQueueStore/store/queues/REGISTRATION/registration disappeared and the system now seems to be checking in and selecting updates.
# 10
cctransport was not running in my case. It had apparently been 'locked down' via a security script.Are each of the 'cc' scripts needed in order for the Sun update connection to function
# 11
Yes, each of the scripts listed is required for Sun Update Connection to function properly.
# 12
Thanks for the help, everything is working properly now. :)
