Segfault VPN клијента на Pi? Прво забележите процес
Љуска исписује segmentation fault и картица се поново флешује. Забележите извршну датотеку, верзију и запис о паду пре него што замените било коју опрему.
Покренете клијента, терминал испише Segmentation fault (core dumped), а следећи сат оде на поновно флешовање картице. Та порука описује како је један процес умро у једном тренутку. Не каже да је плоча оштећена и не ослобађа напајање, складиште ни слику од сумње.
Крените од реда који је љуска исписала назад ка процесу иза њега. Корисне чињенице су која је извршна датотека пала, у ком окружењу и у којој фази везе.
Почните од реда који је љуска исписала
Име у вашој наредби често је омотач или покретач који покреће другу бинарну датотеку, па потврдите коју је извршну датотеку језгро заиста прекинуло. Запишите пуну путању, верзију пакета и апликације, архитектуру, издање ОС-а и језгра, налог који ју је покренуо и тачно време. Љуска наредба названа по VPN-у лако може покренути помоћни процес, а запис ће именовати тај помоћни процес. Копирање верзије из пакета инсталираног прошлог месеца не говори ништа о томе шта је радило.
Забележите шта је непосредно претходило паду: покретање, парсирање профила, аутентификација или сесија која је већ пропуштала саобраћај. Те четири фазе сужавају претрагу много више од речи segfault. Сачувајте кратак прозор лога око тог догађаја и оставите нагађања о томе која је недавна промена то изазвала док запис то не каже.
Проверите постоји ли слика меморије
Референца за core датотеку описује дамп као слику меморије процеса записану при прекиду и наводи услове који то писање спречавају. Ти услови укључују нулти лимит ресурса и core образац који дамп усмерава изван радног директоријума. Недостатак датотеке под именом core стога не доказује ништа о томе да ли је дошло до пада. Проверите конфигурисани образац и лимит пре него што закључите да систем није произвео доказ.
На систему који користи systemd kolektor, подржани приказ повезује сачувани запис са извршном датотеком и временом. Запис у журналу и читљива слика меморије два су различита артефакта: политика задржавања и дозволе могу вам оставити једно без другога. Питајте дистрибуцију или одржаваоца апликације за дијагностички ток рада који подржавају, јер trace из другог build-а или другог скупа библиотека обично троши њихово време.
sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn
Поновите та читања на машини која је стварно пала. Радити их на свежој инсталацији одговара на питање које нико није поставио.
Третирајте дамп као материјал који носи тајне
Меморија процеса може садржати акредитиве, сесијске кључеве и садржај профила, што дамп чини осетљивијим од текстуалног лога поред њега. Редактирање лога не чини ништа за непрозирну слику меморије, а обични issue tracker-и чувају прилоге много дуже него што траје нит подршке. Преместите датотеку приватним каналом који продавац или одржавалац пружа. Објављивање сировог дампа у јавном issue-у излаже све што је било у меморији кад је процес умро, а не можете знати шта је то било док неко не прегледа.
Ако одржавалац тражи trace, питајте из које извршне датотеке и којих библиотека га желе. Backtrace чији се оквири не поклапају са пријављеним build-ом тешко је поверовати и лако погрешно прочитати.
Проверите порекло пре него било шта замените
Проверите порекло пакета и интегритет датотека код онога који поседује инсталацију и сачувајте конфигурацију и идентитетски материјал пре сваке контролисане поправке. Не пребришите једину копију доказа само да видите покреће ли се чиста инсталација. Свежа слика која се подиже каже да се нова слика подиже. Не каже је ли стара садржавала корумпиран пакет, картицу која отказује или бинарну датотеку која је увек требало да падне на овој архитектури.
Ако и неповезани програми падају, или систем логује грешке складишта, напајања или језгра, сачувајте та запажања за истрагу платформе. Она проширују обим; не доказују да сваки segfault долази од RAM-а који отказује или корумпиране слике.
Након циљане поправке поновите исто одобрено покретање и исту VPN операцију на истом хардверу. Реците која је грешка престала и под којом верзијом. Чисто подизање само по себи ни не идентификује неисправну компоненту ни не предвиђа следећи хардверски квар.