Why don't we ask for kern.log?

Jeremy Foshee jeremy.foshee at canonical.com
Tue Jul 20 10:27:33 UTC 2010


On Tue, Jul 20, 2010 at 12:29:16AM -0400, Steven wrote:
> Thanks JFo, great response as always :)
> 
> My main question was whether there was a specific reason for me *not* to ask
> for kern.log, such as personal info or other rules it would break or problems
> it would cause. Good to know that's not the case.
> 
> I work triaging xserver-xorg-video-intel bugs, so when X freezes, you usually
> can't switch to another VT, so the only way to get dmesg is to ask the reporter
> to SSH in, which requires another computer and a good deal of technical
> know-how. Thus I find it easier to just ask for kern.log after they recover.
> 
> Technically I guess I could ask for dmesg.0 instead, but drm.debug makes this
> so verbose that it fills the buffer too quickly and only contains the boot
> info, so we usually lose the dmesg for the actual error, since it usually
> occurs after the buffer's already filled up. So asking for kern.log is rather
> foolproof in these cases.
>
Actually, kern.log would be perfect in those situations, as you point
out. The team agrees. This is oen of those use cases that wasn't thought
of at the time. The consensus is, kern.log is perfect for your use case,
but we probably won't add it to the apport log collection due to it
being extra for most of the bugs that get filed.

Hope that helps. :-) 
> Thanks again for the detailed response.
My pleasure, as always.
> 
> -Steven
> 
~JFo
> 
> On Mon, Jul 19, 2010 at 6:37 AM, Jeremy Foshee <jeremy.foshee at canonical.com>
> wrote:
> 
>     On Fri, Jul 09, 2010 at 01:37:25PM -0700, Brian Murray wrote:
>     > On Fri, Jun 25, 2010 at 10:27:48PM -0400, Steven wrote:
>     > > Hi, I was curious why I haven't seen anyone ask for kern.log,
>     especially for
>     > > kernel or graphics bugs. Is there sensitive information in there? Is
>     the
>     > > computer name too private?
>     > >
>     > > It seems much easier to ask for kern.log than dmesg, since:
>     > > 1) If the system freezes and you have to reboot, dmesg and /var/log/
>     dmesg
>     > > aren't relevant anymore, so uploading kern.log guarantees you have the
>     > > correct dmesg for the bug.
>     > > 2) The timestamps make it very easy to pinpoint where the error should
>     be
>     > > and lessen the chance to misinterpret irrelevant messages as messages
>     that
>     > > are related to the bug.
>     >
>     > This is a great question and hopefully Jeremy, who I am cc'ing, can shed
>     > some light on it.
>     >
>     So, I took some time to talk to the team face-to-face on this. Apologies
>     for the delay that caused. :)
> 
>     The long answer is that we generally get what we need from dmesg. Even
>     given your argument that kern.log is persistent when the system crashes,
>     the consensus is that we would not really get anything useful from
>     kern.log in those cases. As to the timestamps, we ask that the
>     collection occur at the time of the error in most cases. This allows us
>     to have the current information in a much smaller log to review.
>     At some point in the recent past, the logging that we requested was
>     discussed and the most useful logs were selected
>     for inclusion in bugs for the apport-collect command to gather. We
>     periodically review this listing, much like we have just done as a
>     result of this query :).
> 
>     I hope this information is useful. I've written this rather quickly, so
>     please feel free to let me know if it isn't making sense somewhere. :-)
> 
>     ~JFo
>     > --
>     > Brian Murray
>     > Ubuntu Bug Master
> 
> 
> 
> 




More information about the Ubuntu-bugsquad mailing list