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): 2.9.13-7.x.9 How Reproducible: 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. 3. Actual Results: 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. Expected Results: Packages successfully download and are updated. Additional Information: 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 as much). 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.