[lkml]   [2017]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Help with trace-cmd/ftrace recording process ID information
On Mon, Jul 17, 2017 at 4:17 PM, Steven Rostedt <> wrote:
> On Mon, 17 Jul 2017 16:06:37 -0400
> Will Hawkins <> wrote:
>> This seems to be the problem:
>> On the "good" system, that file is up-to-date with cached PIDs and
>> comms. On the bad host, there are no cached entries from any of the
>> traces that I've run.
>> Because these are running old kernels, there is no saved_cmdlines_size
>> knob to turn. Do you have any idea why the saved_cmdlines would not be
>> getting updated appropriately on the "bad" host? I know this is not
>> ideal, but I can try to reboot that host and see if something is
> Yeah, a reboot may work.
>> simply wedged. The system has been online for almost a year, so it's
>> possible that something has gone wrong.
>> Any help you can offer would be great! Thank you, again, for your response!
> The recording of command lines only happens when tracing is done, and
> there were a few bugs with the older kernels that caused it to either
> stop and never start again, or to simply just miss a bunch of recording.
> It may be that it stopped and never started again, so you will only
> have a stale file.

This appears to have been the problem! I did a reboot and everything
is back to normal.

Is there a way to poke at the tracing infrastructure in the kernel to
get it to restart process recording? I would feel more comfortable
with a solution like that instead of rebooting, obviously. The 'ol
Windows "solution" makes me queazy :-)

Thanks again for your quick responses. I hope that I can repay you at
some point by contributing code to the great tools you've built!


> -- Steve

 \ /
  Last update: 2017-07-18 00:34    [W:0.059 / U:2.988 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site