New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 701271 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

generate_logs should contain more logs

Project Member Reported by cychiang@chromium.org, Mar 14 2017

Issue description

Currently it only dumps logs under /var/log.
It should have more information.
audio_diagnostics is the most useful one.
Other things under debugd/src/log_tool.cc are useful too.


 
Cc: philipchen@chromium.org diand...@chromium.org
Labels: -Pri-1 OS-Chrome Pri-2
Jimmy, are you actually working on this?

In other contexts, we've found it unfortunate that we don't capture console-ramoops with this either (and so when ODMs capture logs that way, we don't get enough info to resolve their problems). As long as we add new entries to log_tool.cc that don't automatically become part of DebugLogsTool::GetDebugLogs(), then this will probably be a nagging problem.

Anyway, reducing from Pri-1, because obviously it wasn't Pri-1 :D

Comment 2 by vapier@chromium.org, Mar 15 2018

Labels: -Type-Bug Type-Feature
generate_logs is currently meant to only slurp up /var/log.  the other sources are via feedback log end points in debugd.

what are you guys using generate_logs for ?
Owner: ----
Status: Untriaged (was: Started)
Previously, partners always use generate_logs when they report issues.
Now they know they can use audio_diagnostics command. It is fine for me that generate_log does not contain audio_diagnostic result.
So I am no longer working on this.

Thanks!
Cc: dnschn...@chromium.org
Components: Internals>Logging OS>Systems
Owner: briannorris@chromium.org
Status: Assigned (was: Untriaged)
> what are you guys using generate_logs for ?

I'm not particularly using it, but somehow partners (e.g., factory teams) have gotten it in their head as a great way to capture logs. I don't know all reasons, but I expect many factories don't have amazing (or liberated) connectivity, so feedback reports might not make it out to the network very easily.

For my sake: it's generally easier to have a simple 1-liner to recommend to people than describe the N different places I want them to grab stuff from. I've tried to give better instructions, but they still have a high failure rate on actually following them.

See some other related stuff:

Example partners recommending generate_logs: https://b.corp.google.com/issues/35585050

Issue 690134 - prior requests to extend generate_logs (not currently covered in my plans)

Other prior complaints:
https://bugs.chromium.org/p/chromium/issues/detail?id=689585#c8

Would it be that bad to, e.g., extend generate_logs to just grab the full feedback logs (e.g., LogTool::GetAllLogs()) and drop that in the tarball too? I'll assign to myself, with the idea that I might do that. I could also look at slurping in /var/spool/crash/, to kill issue 690134.

Comment 5 by vapier@chromium.org, Mar 16 2018

i'm OK with expanding things specifically for devs grabbing things by hand, i just don't want this turning into "ABI" or automated customer usage.  does that make sense ?

maybe we can make it explicit in the generate_logs --help, and whenever you run the command it dumps a warning.
> expanding things specifically for devs grabbing things by hand,

Exactly. Where "dev" may vary in their ability or desire to perform complicated reasoning about what exactly is useful for debugging.

> i just don't want this turning into "ABI" or automated customer usage.  does that make sense ?

I'm not sure I'm parsing what exactly is the difference between devs and customer usage, such that one is an ABI and another isn't. How would a customer be using it differently than a dev? In all cases, they'd have to be in dev mode. (Or are you referring to the chrome://chrome#chromeos method of grabbing logs?)

BTW, apparently even our QA team has been taught to use this script, and so even *they* don't capture the necessary info. See issue 820307.
Status: Started (was: Assigned)
CL for review:
https://chromium-review.googlesource.com/c/chromiumos/platform2/+/991610

Fun side note: I noticed Mike had this CL outstanding, and it would add one more piece of info that is present only in feedback reports, with the added bonus that it *used* to go to /var/log/ (and therefore to generate_logs tarballs). I refreshed it, fixed it, tested it, and put it on top of my work, so we can avoid losing this info from debug-logs ;)

https://chromium-review.googlesource.com/c/chromiumos/platform2/+/768854
Project Member

Comment 8 by bugdroid1@chromium.org, Apr 12 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/ca4fc043bddd79aa08d28f7be65134707511f0bc

commit ca4fc043bddd79aa08d28f7be65134707511f0bc
Author: Brian Norris <briannorris@chromium.org>
Date: Thu Apr 12 11:25:19 2018

debugd: grab all feedback logs when stashing "debug logs"

Various parties like to use the `generate_logs` script as a
one-stop-shop for retrieving various system logs. Unfortunately, the
current logs it captures are woefully inadequate for a variety of cases;
it only captures /var/log/ and some ARC logs (logcat?), but it misses
audio diagnostics, console-ramoops, firmware logs, and plenty more.

Most of this useful type of information is already well-maintained in
the endpoint used for generating feedback reports and similar (LogTool).
Let's make use of that instead, by customizing the existing
"GetAllLogs()" to also get ARC++ logs (which debug_logs_tool.cc already
had special-case code for).

BUG= chromium:701271 
TEST=`generate_logs`

Change-Id: I157c27c31884b37d102dea328352829161d293b9
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/991610
Reviewed-by: Ben Chan <benchan@chromium.org>

[modify] https://crrev.com/ca4fc043bddd79aa08d28f7be65134707511f0bc/debugd/src/debug_logs_tool.cc
[modify] https://crrev.com/ca4fc043bddd79aa08d28f7be65134707511f0bc/debugd/tools/generate_logs.cc
[modify] https://crrev.com/ca4fc043bddd79aa08d28f7be65134707511f0bc/debugd/src/log_tool.cc
[modify] https://crrev.com/ca4fc043bddd79aa08d28f7be65134707511f0bc/debugd/src/log_tool.h
[modify] https://crrev.com/ca4fc043bddd79aa08d28f7be65134707511f0bc/debugd/src/debugd_dbus_adaptor.cc
[modify] https://crrev.com/ca4fc043bddd79aa08d28f7be65134707511f0bc/debugd/src/debug_logs_tool.h

Project Member

Comment 9 by bugdroid1@chromium.org, Apr 12 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/793510fddfa09e3f45fdc36dca8a6a73b0e5a9bc

commit 793510fddfa09e3f45fdc36dca8a6a73b0e5a9bc
Author: Brian Norris <briannorris@chromium.org>
Date: Thu Apr 12 11:25:20 2018

debugd: generate_logs: complain about excess args

The FlagHelper class is weird, in that it doesn't accept flags with a
space between the flag and arg -- e.g., '--output foo' ignores 'foo'
without complaining, and leaves 'foo' as a leftover arg for the caller
to handle. (The user was supposed to know to type '--output=foo'.)

Instead of improve (and possibly break some users of) FlagHelper, let's
just complain if there are any args leftover. This way `generate_logs
--output /tmp/foo` gives a nice error message instead of generating
/tmp/debug-logs_TIMESTAMP.tgz.

BUG= chromium:701271 
TEST=`generate_logs --output /tmp/foo` and
     `generate_logs --output=/tmp/foo`

Change-Id: I8d499052af18bc3b1ca64f975f58e024a86b6627
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/996589
Reviewed-by: Ben Chan <benchan@chromium.org>

[modify] https://crrev.com/793510fddfa09e3f45fdc36dca8a6a73b0e5a9bc/debugd/tools/generate_logs.cc

Status: Fixed (was: Started)
w00t

Sign in to add a comment