On Mon, Jul 17, 2017 at 4:17 PM, Steven Rostedt <[email protected]> wrote: > On Mon, 17 Jul 2017 16:06:37 -0400 > Will Hawkins <[email protected]> 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! Will > > -- Steve
