Thank you Pete. I will make a note of your instructions and try to get the identity of the application responsible to triggering the loop next time it happens.
At the present time the ~/.cache/upstart/hud.log does not contain the string "safety" ... but you did not expect it would after a reboot.
I will install d-feet. Can I invoke d-feet __after__ the onset of the 100% CPU problem? or does it have to be running all the time to be ready to trap the problem?
Let me just repeat back the instructions as I understand them, to make sure I have it right. When this problem happens again, first search the ~/.cache/upstart/hud.log for the string "safety-valve" and look for an app ID in the form similar to ":1.22". Then invoke d-feet and scan for the matching app ID. When I cursor over the matching app ID, the bottom left corner of the d-feet window should identify the app that triggered the polling loop. Then I will notify you by posting the info here and at that point it is OK to reboot the 100%-CPU system.
Thank you Pete. I will make a note of your instructions and try to get the identity of the application responsible to triggering the loop next time it happens.
At the present time the ~/.cache/ upstart/ hud.log does not contain the string "safety" ... but you did not expect it would after a reboot.
I will install d-feet. Can I invoke d-feet __after__ the onset of the 100% CPU problem? or does it have to be running all the time to be ready to trap the problem?
Let me just repeat back the instructions as I understand them, to make sure I have it right. When this problem happens again, first search the ~/.cache/ upstart/ hud.log for the string "safety-valve" and look for an app ID in the form similar to ":1.22". Then invoke d-feet and scan for the matching app ID. When I cursor over the matching app ID, the bottom left corner of the d-feet window should identify the app that triggered the polling loop. Then I will notify you by posting the info here and at that point it is OK to reboot the 100%-CPU system.