Brock Pytlik wrote: > 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,
One thing that came into my mind, Could you check ownership/permissions of the opensolaris-lastcheck file? best Michal > > 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
