0 available, 11 in progress?
Have a system that I applied patches to last week, all of the available. Did an init 6 to get the ones that required restarts to be installed. System came back up and it still said there were 11 "in progress". Manually ran smpatch update and did an init 6 again this week and now it says there are 0 updates available but the 11 that were in progress are still there. smpatch analyze on the system shows 0 available. Can't cancel or archive the in progress jobs.
[470 byte] By [
dyoung2] at [2007-11-26 6:04:07]
# 1
I just noticed, I have 2 systems that are doing the exact same thing.
# 2
Patches requiring a reboot should be installed by the "installupdates" script when the system is being shutdown. The script should be present under /etc/init.d/installupdates, /etc/rc0.d/K51installupdates and /etc/rcS.d/K51installupdates.
Can you check for a "/var/sadm/spool/disallowed_patch_list" file which should contain a list of patches to be applied?
After the installupdates script is run, a /var/sadm/spool/disallowed_patch_list_report file should be created with any errors. Can you check if this has been created and if it contains any errors?
# 3
The file is there and has the following contents:
root@gsbids2:[spool]$ more disallowed_patch_list_report
STATUS INSTALL BEGIN 118371-04
Transition old-style patching.
STATUS INSTALL END 118371-04 INSTALL.0
These systems are completely up to date yet still the portal still says there are 11 updates "in progress".
# 4
Could you send us the following information from both hosts so that we can escalate this issue:
# hostname; hostid
# /usr/lib/cc-ccr/bin/ccr -g cns.assetid
# "showrev -p | grep <patch numbers>" output showing that the 11 in progress patches are actually installed.
# Your login username
You can email the output to "rsc-forum-inbound@sun.com" instead of posting it on this forum. Be sure to include a link to this thread in the email you send.
# 5
It is possible ( as you have seen ) for a in-progress task to get 'stuck'. This can happen if the swup agent ( swupas ) is killed ( manually or via a reboot ) while attempting to handle the request. It is my understanding that after 3 days these stuck tasks will be purged from the systems.
I see that you reported the incident at the 20th and on the 22nd they were still there. Are they gone now?
We are also tracking another issue that might lead to tasks getting 'stuck' in the in-progress state. Once I have more information I will update this post.
# 6
They're still out there.
# 7
root@gsbids1:[root]$ hostname
gsbids1
root@gsbids1:[root]$ domainname
gsb.uchicago.edu
root@gsbids1:[root]$ hostid
838d9525
root@gsbids1:[root]$ showrev -p | grep 119990-01
Patch: 119990-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
root@gsbids1:[root]$ showrev -p | grep 119986-01
Patch: 119986-01 Obsoletes: Requires: Incompatibles: Packages: SUNWcsu
root@gsbids1:[root]$ showrev -p | grep 119906-02
Patch: 119906-02 Obsoletes: Requires: Incompatibles: Packages: SUNWgnome-vfs
root@gsbids1:[root]$ showrev -p | grep 120627-01
Patch: 120627-01 Obsoletes: Requires: Incompatibles: Packages: SUNWnfssu
root@gsbids1:[root]$ showrev -p | grep 119988-01
Patch: 119988-01 Obsoletes: Requires: Incompatibles: Packages: SUNWxcu4
root@gsbids1:[root]$ showrev -p | grep 118551-02
Patch: 118551-02 Obsoletes: Requires: Incompatibles: Packages: SUNWmdr, SUNWmdu, SUNWhea
root@gsbids1:[root]$ showrev -p | grep 120099-03
Patch: 120099-03 Obsoletes: Requires: Incompatibles: Packages: SUNWapbas
root@gsbids1:[root]$ showrev -p | grep 119542-05
Patch: 119542-05 Obsoletes: Requires: Incompatibles: Packages: SUNWgnome-desktop-prefs-share, SUNWgnome-desktop-prefs
root@gsbids1:[root]$ showrev -p | grep 120458-01
Patch: 120458-01 Obsoletes: Requires: Incompatibles: Packages: SUNWgnome-config
root@gsbids1:[root]$ showrev -p | grep 119410-02
Patch: 119410-02 Obsoletes: Requires: 119370-01 Incompatibles: Packages: SUNWgnome-utility-applets, SUNWgnome-dictionary, SUNWgnome-internet-applets, SUNWgnome-intranet-applets, SUNWgnome-mm-applets
root@gsbids1:[root]$ showrev -p | grep 119117-05
Patch: 119117-05 Obsoletes: Requires: Incompatibles: Packages: SUNWevolution-libs, SUNWevolution-share, SUNWevolution
root@gsbids1:[root]$
updates login is youngd24
Sent email to that address as well.
# 8
Bummer, then you are definitely running into the issue we are actively researching. I'll post the bug id and workaround once I get them.
# 9
ok, I didn't touch a thing and haven't even tried to do any updates but now instead of 11 in progress the patch portal shows 44 in progress on this node.
# 10
I have/had a similar issue, with 75 patches... The updates seemed to go fine, the update manager asking me to reboot and all... After reboot, I still had the same 75 patches... I did a manual "smpatch update", which seem to install a bunch of patches that appeared to be stuck... I know have 37 patches left that seem stuck...
In my disallowed_patch_list_report, I got a bunch of:
STATUS INSTALL BEGIN XXXXX
Transition old-style patching.
STATUS INSTALL END XXXXX INSTALL.1
# 11
Any updates on this? The same jobs have been out there for almost 2 months now.
# 12
Same here...Last night I went through a batch of patches, and still after that the same 37 "sticky" ones remain...
# 13
This is the same bug (introduced by 121086-01) that has been discussed in several other threads.
The updated patch is supposed to be out any day now.
But a simple workaround is available and has been posted several times.
ln /etc/init.d/installupdates /etc/rc0.d/K51installupdates
ln /etc/init.d/installupdates /etc/rcS.d/K51installupdates
and shutdown/reboot
# 14
Well, didn't have time to get back to this system and it's still showing as 11 in progress. Those symlinks already exist on the machine as well .Did an smpatch update which worked and restarted the machines. However, the portal says 11 in progress (still), after many, many weeks.
