Как включить отчеты о сбоях / дампы ядра / протоколирование трассировки стека глобально?

9

Сбои ошибок могут быть самыми раздражающими, приводящими к потере данных, простоям и разочарованным пользователям. Было бы хорошо, если бы приложения меньше зависали.

Из-за сложности машинного контекста сбой часто не может быть воспроизведен в разумные сроки для обычного пользователя. Это не означает, что ошибка встречается редко - это может означать, что то, что вызывает ее, редко происходит для каждого пользователя (например, изменения летнего времени). Такие ошибки вряд ли будут исправлены, если многие пользователи не сообщат о них. Было бы хорошо, если бы сообщалось о новых авариях.

Для устранения сбоев разработчикам нужно как можно больше однозначного контекста. Созданные отчеты о сбоях хороши , потому что они обычно подробны и точны. Нельзя ожидать, что пользователи усердно наблюдают и сообщают обо всем контексте вручную, поэтому они часто предоставляют скудную и неверную информацию.

Целевая аудитория для многих приложений - это не разработчики или системные администраторы, а широкая публика, дома или на работе. Нельзя ожидать, что такие пользователи будут знать, как собирать информацию о -dbgсбоях вручную или устанавливать пакеты, но сгенерированные отчеты от таких пользователей все еще можно использовать. Некоторые приложения имеют свои собственные инструменты для отчетов о сбоях , но по моему опыту они редко работают , и когда они сообщают, что не смогли сообщить об ошибке, кажется, нет никакой информации о том, как сделать это вручную (я наблюдал это для последние версии как Firefox, так и Flash). Общесистемное создание отчетов о сбоях было бы хорошо.

Существует ли какой-либо тип генерации отчетов о сбоях *, который можно включить глобально ** без установки тонны -dbgпакетов, чтения документации каждого приложения или замедления нормальной работы компьютера до сканирования?

* Журналы, дампы ядра, следы стека, что угодно

** Не обязательно для init, но по крайней мере для значительного подмножества приложений, работающих на типичной настольной установке Linux. По моему опыту, GUI-приложения аварийно завершают работу в 100 и более раз чаще, чем приложения оболочки, поэтому приложения GUI, естественно, будут в центре внимания.

debugging l0b0
источник
Что бы вы сделали со всеми этими основными файлами (да, вы можете включить дампы ядра глобально, но приложения могут по отдельности отключить их)? Как вы обучаете пользователей тому, что с ними делать, как их чистить?
Мат
1
Отправьте их разработчикам. По крайней мере, большинство из них должны быть знакомы с вложениями электронной почты.
10
1
Как насчет вопросов безопасности? основные дампы могут быть полны личной информации. Извините, но я не видел ничего общего с тем, что вы предлагаете.
Мат
Отчеты о сбоях и трассировки стека, с другой стороны, не должны содержать никакой личной информации. Даже этого должно быть достаточно для отладки многих приложений, если они были созданы только по умолчанию и их легко найти.
10
1
Трассировки стека не так уж полезны без отладочной информации (или, по крайней мере, с точными двоичными версиями, которые идут вместе с ними). «Отчет о сбое» - это концепция уровня приложения, а не то, что вы могли бы «включить глобально» (хотя некоторые фреймворки предоставляют их, а крупные (например, KDE) уже имеют автоматические функции «отправить в группу разработчиков»).
Мат

Ответы: