Red Hat Bugzilla – Bug 69946
Up2date can run so slowly that the authorization from RHN times out.
Last modified: 2015-01-07 18:58:11 EST
Description of Problem:
Running up2date --nox --nosig -u takes so long on my dual PPro 200 w/192MB
RAM that it gets just a couple or a few packages downloaded before it exits
with a fatal error message about the authorization failed.
Version-Release number of selected component (if applicable):
The more times you run up2date the more packages it will download -- the first
time through didn't download any packages.
Steps to Reproduce:
1. up2date --nox --nosig -u
2. Wait a little over an hour.
Fatal error and an exit. Sometimes this is with a few packages downloaded,
and sometimes it isn't. I haven't run it enough times to get all the packages
to download as yet. Good thing I'm not on dialup.
Packages successfully download and are updated.
Up2date should have a way of keeping the authorization valid during its run,
with the authorization expiring only after up2date completes, rather than a
strict timeout. Something like a keepalive.
When in BugFree(tm) mode, up2date automatically reacquires
authentication tokens when it's previous ones expire and
do this transparently (aside from a log message indicating
However, were not quite in BugFree(tm) mode yet. A bug
in rhnlib was returing the wrong error codes in this
circumstance and up2date was never updating the auth.
Current versions (2.9.30 for up2date and er, 0.8-10 or so
I belive) should fix this.
2.9.30 does indeed fix this portion of the problem.
However, it appears that with free entitlements it is possible to lose the
server to a 'free connections are being shut down' type error. I saw this
very thing a few days ago, where the download started and was aborted after
downloading some packages -- there is no option available except 'click OK to
close' -- and then up2date has to be rerun.
An option to 'would you like to purchase Red Hat Network entitlements to
eliminate this error' might be appropriate at that point -- or at least a
'retry' or 'schedule completion for later' might be in order, particularly on
slower machines where an up2date run can be hours long.
I'm not reopening the bug, however. Just making the note.