Segfault на VPN клиента на Pi? Първо запечатайте процеса

Стартирате клиента, терминалът отпечатва Segmentation fault (core dumped) и следващият час отива в префлашване на картата. Това съобщение описва как един процес е умрял в един момент. То не казва, че платката е повредена, и не оневинява захранването, носителя или образа.

Тръгнете от реда, който обвивката отпечата, обратно към процеса зад него. Полезните факти са кой изпълним файл се е провалил, в каква среда и на кой етап от връзката.

Започнете от реда, който обвивката отпечата

Името в командата ви често е обвивка или стартер, който пуска друг двоичен файл, затова потвърдете кой изпълним файл ядрото действително е прекратило. Запишете пълния път, версията на пакета и приложението, архитектурата, версията на операционната система и ядрото, акаунта, който го е стартирал, и точното време. Shell команда, наречена на VPN, лесно може да стартира помощен процес и записът ще посочи помощния процес. Копирането на версията от пакет, инсталиран миналия месец, не ви казва нищо за това какво е работило.

Отбележете какво непосредствено е предхождало срива: стартиране, разбор на профил, удостоверяване или сесия, която вече е пропускала трафик. Тези четири етапа стесняват търсенето много повече от думата segfault. Пазете краткия прозорец от логове около събитието и оставете догадките коя скорошна промяна го е причинила, докато записът не го каже.

Разберете дали съществува образ на паметта

Справката за core файл описва дъмпа като образ на паметта на процеса, записан при прекратяване, и също изброява условията, които спират това записване. Тези условия включват нулев лимит на ресурси и core pattern, който насочва дъмпа някъде извън работната директория. Липсващ файл с име core следователно не доказва нищо за това дали е имало срив. Проверете конфигурирания pattern и лимита, преди да заключите, че системата не е създала доказателство.

На система с колектора на systemd поддържаният изглед свързва запазен запис с изпълним файл и време. Запис в журнала и четим образ на паметта са два различни артефакта: политиката за съхранение и правата могат да ви оставят с единия без другия. Попитайте дистрибуцията или поддръжника на приложението за диагностичния работен процес, който поддържат, защото трасета от различен билд или различен набор библиотеки обикновено губи времето им.

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

Повторете тези четения на машината, която действително е паднала. Правенето им на чиста инсталация отговаря на въпрос, който никой не е задал.

Третирайте дъмпа като материал, носещ тайни

Паметта на процеса може да съдържа идентификационни данни, сесийни ключове и съдържание на профил, което прави дъмпа по-чувствителен от текстовия лог до него. Редактирането на лога не прави нищо за непрозрачен образ на паметта, а обикновените issue tracker-и пазят прикачените файлове много по-дълго, отколкото трае една поддържаща тема. Преместете файла по частния канал, който доставчикът или поддръжникът предоставя. Публикуването на суров дъмп в публичен issue разкрива всичко, което е било в паметта, когато процесът е умрял, и не можете да знаете какво е било, докато някой не го прегледа.

Ако поддръжник поиска трасе, попитайте от кой изпълним файл и кои библиотеки го искат. Backtrace, чиито кадри не съвпадат с отчетения билд, е труден за доверие и лесен за погрешно четене.

Проверете произхода, преди да смените нещо

Проверете произхода на пакета и целостта на файловете чрез този, който притежава инсталацията, и запазете конфигурацията и идентичностните материали преди всяка контролирана поправка. Не презаписвайте единственото копие на доказателството само за да видите дали чиста инсталация стартира. Пресен образ, който стартира, ви казва, че новият образ стартира. Той не ви казва дали старият е съдържал повреден пакет, повредена карта или двоичен файл, който винаги е щял да се срине на тази архитектура.

Ако и несвързани програми се провалят, или системата логва грешки в носителя, захранването или ядрото, запазете тези наблюдения за разследването на платформата. Те разширяват обхвата; не доказват, че всеки segfault идва от повредена RAM или развален образ.

След целенасочена поправка повторете същото разрешено стартиране и същата VPN операция на същия хардуер. Кажете кой отказ е спрял и при коя версия. Чистото стартиране само по себе си нито идентифицира дефектен компонент, нито предсказва следващата хардуерна повреда.