Bug 24091
Summary: | up2date hangs on "Removing packages with files marked to skip from list" | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <linux4us> |
Component: | up2date | Assignee: | Preston Brown <pbrown> |
Status: | CLOSED NOTABUG | QA Contact: | Jay Turner <jturner> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | linux4us, srevivo |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-03-10 05:06:09 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2001-01-16 05:12:12 UTC
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> |