Feedback reports sometimes don't include any data from debugd |
|||||
Issue descriptionFor a few years now, I've occasionally seen feedback reports whose system_logs.zip files are missing a bunch of data. For example, see http://feedback/product/208/neutron?lView=rd&lReport=59249325632. When I grep for '=<multiline>$' in its log file, I only see the following entries: Profile[0] chrome_user_log=<multiline> Profile[0] login-times=<multiline> Profile[0] logout-times=<multiline> alsa controls=<multiline> audio_diagnostics=<multiline> cras=<multiline> dbus_details=<multiline> dbus_summary=<multiline> device_event_log=<multiline> disk_usage=<multiline> env=<multiline> extensions=<multiline> hack-33025-touchpad=<multiline> hack-33025-touchpad_activity=<multiline> hack-33025-touchscreen_activity=<multiline> mem_usage=<multiline> modetest=<multiline> network-status=<multiline> network_event_log=<multiline> routes=<multiline> system_files=<multiline> It looks like all of the entries from common_logs in src/platform2/debugd/src/log_tool.cc are missing -- there are no CLIENT_ID (single-line, but not there either), ps, or powerd.LATEST entries, for instance. Is debugd not running? Is Chrome unable to communicate with it? I see this in a Chrome log, which suggests that debugd is broken: [1569:1569:0502/173711.487392:ERROR:object_proxy.cc(583)] Failed to call method: org.chromium.debugd.SetOomScoreAdj: object_path= /org/chromium/debugd: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
,
May 4 2017
No, I don't see anything besides kernel warnings from this client on the crash server. Here are some non-empty feedback reports on either side of the broken one mentioned above: http://feedback/#/Report/59231144211 http://feedback/#/Report/59307852875 If I'd have to guess, I'd speculate that maybe Chrome's D-Bus call to debugd's DumpDebugLogs method is timing out. chromeos/dbus/debug_daemon_client.cc looks like it uses a two-minute timeout. As a side question, is debugd multithreaded or asynchronous in any way, or is it blocked while it's collecting logs? The SetOomScoreAdj timeout above seems troubling. Is that call important? Why are we using debugd for it instead of putting it in e.g. session_manager?
,
May 4 2017
,
May 4 2017
I think that's for ARC++. My next big project is going to be splitting off logs stuff away from debugd.
,
May 4 2017
I don't think debugd is multithreaded, or else it would be littered with races. The conversion to chromeos-dbus-bindings is going to render that moot, in any event.
,
May 4 2017
I think chrome's DebugDaemonLogSource calls debugd.GetBigFeedbackLogs (which has a 2-minute timeout) to obtain logs to be included in feedback reports, which seems to serialize logs into a JSON blob and send the blob over a file descriptor that is passed through DBus. I'd guess it probably takes most of the time to gather logs (e.g. spawning processes, etc) *sequentially* than to send the JSON blob over the file descriptor. As more logs are being added, we probably want to revisit how debug::LogTool should invoke helpers to gather logs. Also, not sure if it's related, when looking into the chrome feedback code a while ago, I noticed some code in chrome that seems to duplicate the functionalities of debugd. For example, the SystemLogUploader seems to include a subset of system logs. <chrome>/src/chrome/browser/chromeos/system_logs/ <chrome>/src/chrome/browser/chromeos/policy/system_log_uploader.cc <chrome>/src/components/feedback/anonymizer_tool.h
,
Jun 21 2017
,
Sep 18
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by jorgelo@chromium.org
, May 4 2017