crash-reporter: make unclean shutdowns into crash reports |
||
Issue descriptioncurrently crash-reporter has a unclean shutdown collector, but it only processes metrics we now independently have a /mnt/stateful_partition/shutdown_stateful_umount_failure flag which contains extra debug info to try and triage what's unclean, but it doesn't get uploaded or otherwise generate a crash/metric event. this means we have to wait for users to file feedback reports or QA team to notice an issue, and then for us to try and reproduce it locally so we can recreate the logs. but even after that, we don't have a way of knowing whether we've really fixed the issue other than "people stopped complaining". we should combine these and use the extended debug info as the contents of the crash report tnagel: can you check the privacy aspects ? here's the code in question: https://chromium.googlesource.com/chromiumos/platform2/+/release-R69-10895.B/init/chromeos_shutdown - this code normally runs only after all users have been logged out - we explicitly kill all processes with open files to stateful & user mounts (which means all user processes should be killed) - only after all of that, and if we try to unmount the stateful partition, if it fails we collect: - the current set of mounts - if the kernel crashed, it could have a user mount to a USB stick and we'll see the LABEL the user has given it - but this info is also collected in a lot of other reports already - the device mapper info which has basic metadata about the mount and its runtime status - the stateful partition (although once we migrate to ext4 encryption, this would go away) - *not* user cryptohome mounts as they should be ext4 encryption now - any components the system has mounted (although they should have all been unmounted already) - all open files on the system still (excluding network details) - all user and stateful related processes should have been killed twice over by now so basically, the only time we might collect PII is if the kernel crashed or failed in some way, and that's precisely the time when we want it as we need to see what crashed or failed to unmount so we can track it back and fix it.
,
Sep 10
Dear , This review has now been inactive for over 3 days. Could you please take appropriate steps to finish the review? Your friendly privacy review bot.
,
Oct 31
Assigning to tnagel@, since the question in Comment #1 was directed at him.
,
Nov 5
Dear tnagel, This review has now been inactive for over 3 days. Could you please take appropriate steps to finish the review? Your friendly privacy review bot. |
||
►
Sign in to add a comment |
||
Comment 1 by vapier@chromium.org
, Aug 15