Michal Pryc wrote: > 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? > > -rw------- 1 bpytlik staff 13 2008-11-14 16:31 /home/bpytlik/.updatemanager/notify/mountaineer-lastcheck
Is that what it should be? Brock > 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 > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
