Empty jar and zip files in /var/sadm/spool/patchsvr
Is there any relief for this problem? It seems that whenever a client runs smpatch,
the local patch server discards perfectly good jar and zip files and replaces them
with empty files.
find . \( -name '*.jar' -o -name '*.zip' \) -size 0 -exec rm '{}' ';'
works nicely for removing them, but I have to keep doing this. I thought that a
patch was to be available soon!
# 1
Its only been 4 months since they broke it. What are you complaining about.
Oh, you expected that since its a sun product, they might actually test patches before they release them. And spot obvious problems that take people who actually use this software about 5 minutes to realise its completely broken.
And then you expect them to fix their problems within a month or so.
Silly you. You forgot this is update manager. The dumping ground where they stick crappy java programmers who can't be trusted to write real programs. And who they wouldnt let near the kernel in a million years.
Bitter, me. Never :-).
# 2
Unfortunately an official patch has still not been released yet and we too have been awaiting its release. There was an IDR available for testing but it is not the final fix so are no longer providing it to support cases.
# 3
Any further news on the final patch?Regards,Aaron
# 4
Sorry, we havent been given an eta as yet.
# 5
Looks like this patch has just been released.But frankly I believe it works correctly when Ive seen it.Its just been too buggy for too long.
# 6
Yup, like I thought. Its still not completely reliable. Though it is a lot better. Probably to the point of being usable.
So far its worked fine for me for solaris 9 clients.
But on solaris 10 clients, I still get the "patch not found" error.
And its still leaving behind zero length files on the patch proxy.
But a second round of patching was sufficient to get them all.
You'd think after almost 6 months of development, they might have got it right this time.
# 7
Yes. I am still waiting for the patch and I do think Sun could do a better job in this area but I'm not a fan of bagging them out on the forums. It doesn't really help the situation much. The tools are there, I have to use them, there are some bugs and I hope they fix them soon as I have no other complaints.
As far as I am aware I am running all of the latest patches unless something has been released VERY recently.
# 8
This is a recent patch:119788-08 SunOS 5.10: Sun Update Connection Proxy 1.0.9It does contain a bug fix that mentions empty files. I'll be tryingit later today.
# 9
Hope you have better luck with it than I did.
And normally I don't tend to bag out support in the forums.
Their hardworking people doing their job.
But at some stage you just have to say, this is just not good enough and take a stand.
They release a patch in december that 5 minutes of ordinary usage shows is just plain broken. Then they take almost 6 months to release a new version.
And its still broken.
Come on. This just isn't good enough. I have trouble believing just how bad it is.
Ive come to expect better from sun.
# 10
Hmm, I may have been being a little harsh.I cleared out my patchsvr directory and tried a few more machines.No problems seen yet.Heres hoping...
# 11
The local patch server seems to behave better with that patch, or perhaps just
differently. The first two clients I tried got their patches with no difficulty. On a
third one `smpatch analyze' gave the correct patch list, but `smpatch download'
missed several of the patches. When I ran it again, it got the remaining patches.
The empty file problem was intermittent, so it may take a while to determine if
the problem is truely resolved.
# 12
I have this absolutely fantastic idea. How about a single large package you could download and then just run a single script on any host you'd like to patch, to a known good state, reliably, without extra network traffic, once in a while? Oh... that was how it worked, and worked well, before smpatch... 10_Recommended.zip with useful content would get my vote.
Nothing but problems with smpatch. Before the current patch, every time I needed to patch a server or two, I had to restart the LPS and do several iterations of smpatch downloads, cleaning out zero length files from the cache between them. As if that's not enough, the cached patches somehow aren't fresh enough even though they're the same revision; The LPS decides to download patches all over again, taking X amount of extra time and a few extra iterations. It's impossible to plan outages and the process needs constant supervision and tinkering. Even with a policy including rebootimmediate, reconfigimmediate etc. it takes on average at least three runs of smpatch/reboot before hosts are up to date. Is it Microsoft Solaris now?
The amount of work and time I need to put into patching Solaris servers has probably quadrupled after recommended clusters became useless.
With the new patch, all I get is error 500 from the LPS and zillions of lines of java exception crap from clients. Nothing new here. Will try rebooting the LPS just for the hell of it and - sigh - throwing away all 1.5 gigabytes of precious cached patches - yet again.
Just had to let off some steam, sorry (and yes I've already done this to the local Sun representatives a few times as well). Carry on.
# 13
The latest public release of the LPS has resolved a number of issues, although as we have since found out there are still a few glitches to resolve.
One of the issues is that when multiple clients request the same patch (which has not already been cached) at the same time, the second request looks at the patch and realises it is not complete, so deletes the file. This would possibly explain why you are still having to run multiple download runs.
Hopefully we will have another LPS patch released in the very near future, but obviously our engineers are still working out the known issues so I can't provide an ETA as yet.
With regards to patch clusters, as far as I am aware you can still download them from the following URL:
http://sunsolve.sun.com/private-cgi/show.pl?target=patchpage
If you are still having issues with the clients spewing Java errors, have you asked our team to look into this for you on an individual basis? If not then send an email to rsc-forum-inbound@sun.com, or if you would prefer a quicker resolution call your local solutions centre and raise a call for the SWUP Support team.
# 14
Hopefully this update will come out more quickly than the 6 months the last update took.
This helps explain why I have had relatively few problems with it.
Its been a long time since I was silly enough to even try patching two boxes at the same time. That hasnt worked for years.
Shame that the sun engineers have only just realised it. It was pretty obvious...
# 15
We have cron commands that run `smpatch analyze' and `smpatch download' at
random times early on Saturday morning for about 100 servers and workstations.
Since the most recent patch upgrade on the local patch server, this system has been
working very nicely. All of the errors associated with empty files have disappeared.
# 16
I'm still seeing sporadic instances of "patch not found" when I do the smpatch update.But the download itself doesnt produce any errors.But in this case, if you do another download, it brings in some extra patches it missed the first time through..
# 17
I'm also still seeing instances of "WARNING: The installer cannot find the patch" if I do a 'smpatch update'. If I try a download then an update it usually works fine. However, it seems the LPS doesn't like >4-6 machines connecting at the same time, and starts producing errors like this:
119538-11: Request to download update failed. Status code 500 returned.
An unexpected error occurred inside the server that prevented it from fulfilling the request.
I'm guessing the problem corresponds to this error in the LPS logs:
2007-05-16 18:36:47 StandardWrapperValve[PatchsvrServlet]: Servlet.service() for servlet PatchsvrServlet threw exception
java.lang.IllegalStateException (... stack trace ...)
# 18
The issue you see when multiple systems connect at the same time has been noted and is a side effect of the original fix for the problems. You should only see it if more than one client attempts to download/access the same patch at the same time.We expect a fix to be released