If Dan, K, and I have the right handle on things, it would take 1-2 days to reproduce using the steps you're describing. I'm going to try to put together a slightly modified umn which will exhibit the bug in a few minutes. If that doesn't work, I'll take the steps you've described. As a side note, my ~/.updatemanager/notify/opensolaris-lastcheck exists and has a time of last friday in the afternoon, which is roughly when I turned UpdateManager on.
Brock jmr wrote: > Brock - can you: > $ pkill updatemanagernotifier > $ rm ~/.updatemanager/notify/opensolaris-lastcheck > $ /usr/bin/python2.4 /usr/lib/updatemanagernotifier -d > > If this does not chew CPU then come out of it and run it again: > $ /usr/bin/python2.4 /usr/lib/updatemanagernotifier -d > > And send us the output. I'm trying this out on my machine and its > behaving normally, without chewing CPU. I'm running snv_101a on the > metal, on a Mac Book Pro (dual core, 4 Meg RAM), what machine are you on? > > The symptoms you describe are exactly those of 3835. Could you also > send me your /usr/lib/updatemanagernotifier and > /etc/gconf/schemas/updatemanager-preferences.schemas > > I'm not at a build machine, we'll look into it tomorrow. Could you > give Padraig or myself remote access to the box? > > Thanks, > > JR > > Brock Pytlik wrote: >> Brock Pytlik wrote: >>> I'm running rc1.5, and I'm seeing the updatemanagernotifier taking >>> 50% of my CPU, and having a memory footprint of 701M (RSS) 764M >>> (Size). I know bug 3835[1] covered this but the fix went back well >>> before rc1.5. Is it expected that I would be seeing this behavior >>> because I passed through 101a/b, or is this a new problem? When I >>> truss the process, it just spams: >>> ioctl(5, FIONREAD, 0x0804714C) = 0 >>> pollsys(0x083ABBC8, 7, 0x080471E0, 0x00000000) = 0 >>> >>> My gconf values, as shown in gconf-editor are set. Specifically, my >>> refresh period is set to Daily, show_icon_on_startup is off, >>> show_notify_message is on, and the start_delay is 120. My >>> /etc/gconf/schemas/updatemanager-preferences.schemas has a date of >>> 2008-10-30 15:13. Most of my other schemas have a date around >>> 2008-11-14. >>> >>> Is it possible that the update to rc1.5 didn't modify the time stamp >>> of the existing schema file because the file itself had not changed? >>> If so, this seems like fairly broken behavior. >>> >>> >>> [1] http://defect.opensolaris.org/bz/show_bug.cgi?id=3835 >>> _______________________________________________ >>> pkg-discuss mailing list >>> [email protected] >>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >>> >> Just a follow up, DTrace suggests that this is another manifestation >> of 3835. >> 0 247348072612 updatemanagernotifier <- do_next_check >> 0 247348072668 updatemanagernotifier -> do_next_check >> 0 247348072683 updatemanagernotifier -> is_check_required >> 0 247348072699 updatemanagernotifier <- is_check_required >> >> >> Is repeated over and over, and UMN doesn't appear to be doing >> anything else. >> >> Thanks, >> Brock > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
