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
