When I try to use up2date, it consistently hangs on the "Removing packages with files marked to skip from list". CPU usage approaches 99%. The percentage-complete dialogues stop at about 17%. RH 7.0 Kernel: 2.4.0 GNOME: Helixcode 1.2.x (latest available via update). Here's the stdout. After it sat at 17.85% for 5/10 minutes, I killed it, and got the traceback. This is totally repeatable--in fact, I cannot use up2date because of it. This affects both command-line and gnome versions. root@reliant me2v # up2date --list Retrieving list of all available packages... Removing installed packages from list of updates... 100.0% Removing packages marked to skip from list... 100.0% Getting headers for available packages... 100.0% Removing packages with files marked to skip from list... 17.85% root@reliant me2v # Traceback (innermost last): File "/usr/sbin/up2date", line 455, in ? main() File "/usr/sbin/up2date", line 438, in main sys.exit(batchRun(onlyList, pkgNames, fullUpdate)) File "/usr/sbin/up2date", line 170, in batchRun availUpdates, skippedUpdates = up2date.getUpdatedPackageList(printit, percent) File "/usr/share/rhn/up2date/up2date.py", line 990, in getUpdatedPackageList progressCallback) File "/usr/share/rhn/up2date/up2date.py", line 945, in removeSkipFilesPackagesFromList if h['fileflags'][f_i] & rpm.RPMFILE_CONFIG: KeyboardInterrupt root@reliant me2v #
is this up2date 2.1.7?
Yes: me2v@reliant tx9il66p.slt $ rpm -q up2date up2date-2.1.7-1 I've tried recompiling it, with the same results.
I've tried the up2date from fisher, as well. It still does not work (up2date-2.1.7-2). Below is the final part of an strace of 'up2date --list' (up2date --configure seems to work OK): write(3, "\216\2\2\0\3\0\300\3", 8) = 8 ioctl(3, FIONREAD, [0]) = 0 poll( Retrieving list of all available packages... Removing installed packages from list of updates... 100.0% Removing packages marked to skip from list... 100.0% Getting headers for available packages... 100.0% Removing packages with files marked to skip from list... [{fd=3, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = -1 EINTR (Interrupted system call) --- SIGCHLD (Child exited) --- sigreturn() = ? (mask now []) gettimeofday({982431214, 238927}, NULL) = 0 write(3, "+\2\1\0", 4) = 4 read(3, 0xbffff768, 32) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], NULL, NULL, NULL) = 1 (in [3]) write(3, "f\2\3\0\200\0\0\0\1\0\0\0<\0\2\0\0\0\300\3+\0\1\0", 24) = 24 read(3, "\1\2=\0\0\0\0\0\2\0\340\2\0\0\0\0\0\0\0\0\1\0\0\0\370\3"..., 32) = 32 shutdown(3, 2 /* send and receive */) = 0 close(3) = 0 _exit(0) = ? read(3, "\1\2:\0\0\0\0\0\2\0\340\2\0\0\0\0\1\0\0\0\1\0\0\0\370\3"..., 32) = 32 write(3, "f\2\3\0\200\0\0\0\1\0\0\0<\0\2\0\0\0\300\3+\0\1\0", 24) = 24 read(3, "\1\2=\0\0\0\0\0\2\0\340\2\0\0\0\0\0\0\0\0\1\0\0\0\370\3"..., 32) = 32 shutdown(3, 2 /* send and receive */) = 0 close(3) = 0 _exit(0) = ? On configuration, I had "Do not install packages after retrieval" and "Do not display packages when local configuation file has been modified" selected. On a whim, I deselected the configuration file option, and up2date seems to work. The above strace is on the command line. The GUI version just hangs, using all the CPU it can.
Assigned QA to jturner
does this still fail with the wolverine version? Is there a python traceback?
This problem is still present in the current release of up2date (rawhide--not sure if that's different from wolverine, because the version and release are teh same). Note: the problem now exhibits itself if you have: "Display all packages available" and/or "Do not display packages when local configuration file has changed" checked. If neither one of those options are set, then up2date performs normally, afaict (Still waiting for something newer than what's installed already to show up!). If either one of those options are selected, or both, then up2date will hang.
I would tend to bet that there is a circular dependency with the Helix stuff which is causing this problem. I am not able to replicate the problem here on any of the machines that I have tried, using 7.0, the first public beta as well as the second public beta.
I dont think the process is broken. My guess is it has hit the dev package, since the dev package has roughly 15,000 files, it takes a while to iterate though the list. If the config file check is disabled, it skips this step entirely and moves along nice and quickly. I've seen behaviour similar to this in testing. I'll take a look and see if I can special case packages with no configfiles to speed this up. Can you try added "dev" to the list of packages to skip? run `up2date --configure` and add "dev" on the "Package Exceptions" tab, in the "Packages to Skip" area. Then try running with the original config settings, and see if it hangs again.
That last suggestion seems to have done the trick. There may also have been issues with the fact that I have devfs mounted on /dev, so not all the dev rpm stuff was there. There should probably be a way to gracefully cancel checking for a specific package (e.g., "Checking this", "Checking that" cancel that, "Checking other"...). One last thing I'll mention, maybe worth another bug report--the version checking seems somewhat flaky. I've got several packages for which up2date suggests 'updates'--example, I've got ORBit 0.5.7, yet up2date wants to install 0.5.3, and several other packages doing the same thing. This may be due to the underlying rpm foundation, or just flakiness with rpm in general, but it does detract from the usefulness of the tool (which otherwise seems very well done, btw--certainly preferable to Red Carpet!).
remember to check serial numbers on packages before reporting version checking as flakey. The serial number is an internal, "hidden" number that takes precedence over version and release. rpm -q --queryformat "%{SERIAL}\n" <packagename>