Pi પર VPN ક્લાયન્ટ segfault? પહેલાં પ્રક્રિયા કેપ્ચર કરો

તમે ક્લાયન્ટ શરૂ કરો છો, ટર્મિનલ Segmentation fault (core dumped) છાપે છે, અને પછીનો કલાક કાર્ડ ફરી લખવામાં જાય છે. તે સંદેશ વર્ણવે છે કે એક પ્રક્રિયા એક ક્ષણે કેવી રીતે મરી ગઈ. તે કહેતું નથી કે બોર્ડ નુકસાન પામ્યું છે, અને તે પાવર સપ્લાય, સ્ટોરેજ કે ઇમેજને પણ મુક્ત કરતું નથી.

શેલે છાપેલી લાઇનથી પાછળની પ્રક્રિયા તરફ કામ કરો. ઉપયોગી તથ્યો એ છે કે કઈ એક્ઝિક્યુટેબલ નિષ્ફળ ગઈ, કયા પર્યાવરણમાં અને જોડાણના કયા તબક્કે.

શેલે છાપેલી લાઇનથી શરૂ કરો

તમારા આદેશમાંનું નામ ઘણી વાર રેપર અથવા લોન્ચર હોય છે જે બીજી બાઇનરી શરૂ કરે છે, તેથી ખાતરી કરો કે કર્નલે ખરેખર કઈ એક્ઝિક્યુટેબલ સમાપ્ત કરી. પૂરો પાથ, પેકેજ અને એપ્લિકેશન સંસ્કરણ, આર્કિટેક્ચર, OS અને કર્નલ રિલીઝ, જે એકાઉન્ટે તેને શરૂ કર્યું અને ચોક્કસ સમય લખો. VPN નામનો શેલ આદેશ સરળતાથી સહાયક પ્રક્રિયા શરૂ કરી શકે છે, અને રેકોર્ડ તે સહાયકનું નામ લેશે. ગયા મહિને ઇન્સ્ટોલ કરેલા પેકેજની સંસ્કરણ સ્ટ્રિંગ કોપી કરવાથી શું ચાલ્યું તે વિશે કંઈ ખબર પડતી નથી.

ક્રેશ પહેલાં તરત શું આવ્યું તે નોંધો: સ્ટાર્ટઅપ, પ્રોફાઇલ પાર્સિંગ, પ્રમાણીકરણ, અથવા એવું સેશન જે પહેલેથી ટ્રાફિક પસાર કરી રહ્યું હતું. તે ચાર તબક્કા segfault શબ્દ કરતાં ઘણું વધારે શોધ સાંકડી કરે છે. તે ઘટનાની આસપાસની ટૂંકી લોગ વિન્ડો રાખો, અને રેકોર્ડ ન કહે ત્યાં સુધી કયા તાજેતરના ફેરફારે તેને કારણભૂત બનાવ્યું તેવી અટકળો બાજુ પર રાખો.

જાણો કે મેમરી ઇમેજ છે કે નહીં

core ફાઇલ સંદર્ભ ડમ્પને સમાપ્તિ વખતે લખાયેલી પ્રક્રિયા-મેમરીની ઇમેજ તરીકે વર્ણવે છે, અને તે લેખનને અટકાવતી શરતોની પણ યાદી આપે છે. તે શરતોમાં શૂન્ય સંસાધન મર્યાદા અને એવી core પેટર્ન છે જે ડમ્પને કાર્ય ડિરેક્ટરીની બહાર મોકલે છે. તેથી core નામની ફાઇલ ન હોવી કોઈ ક્રેશ થયો કે નહીં તે વિશે કંઈ સાબિત કરતી નથી. સિસ્ટમે કોઈ પુરાવો બનાવ્યો નથી એવું નિષ્કર્ષ કાઢતા પહેલાં ગોઠવાયેલી પેટર્ન અને મર્યાદા તપાસો.

systemd ના કલેક્ટરનો ઉપયોગ કરતી સિસ્ટમમાં, સમર્થિત દૃશ્ય સંગ્રહિત રેકોર્ડને એક્ઝિક્યુટેબલ અને સમય સાથે સહસંબંધિત કરે છે. જર્નલ એન્ટ્રી અને વાંચી શકાય તેવી મેમરી ઇમેજ બે જુદા આર્ટિફેક્ટ છે: જાળવણી નીતિ અને પરવાનગીઓ તમને એક સાથે બીજું ન મળે તેમ છોડી શકે છે. ડિસ્ટ્રિબ્યુશન અથવા એપ્લિકેશનના જાળવનારને પૂછો કે તેઓ કયો ડાયગ્નોસ્ટિક વર્કફ્લો સમર્થન આપે છે, કારણ કે બીજા બિલ્ડ અથવા બીજા લાઇબ્રેરી સેટમાંથી બનેલો ટ્રેસ સામાન્ય રીતે તેમનો સમય બગાડે છે.

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

તે વાંચન જે મશીન ખરેખર ક્રેશ થયું તેના પર પુનરાવર્તન કરો. નવા ઇન્સ્ટોલ પર તે કરવાથી એવા પ્રશ્નનો જવાબ મળે છે જે કોઈએ પૂછ્યો ન હતો.

ડમ્પને રહસ્યો ધરાવતી સામગ્રી તરીકે ગણો

પ્રક્રિયા-મેમરીમાં ઓળખપત્રો, સેશન કી અને પ્રોફાઇલ સામગ્રી હોઈ શકે છે, જે ડમ્પને બાજુના ટેક્સ્ટ લોગ કરતાં વધુ સંવેદનશીલ બનાવે છે. લોગ રિડેક્ટ કરવાથી અપારદર્શક મેમરી ઇમેજ માટે કંઈ થતું નથી, અને સામાન્ય issue ટ્રેકર સપોર્ટ થ્રેડ ટકે તેના કરતાં ઘણા વધુ સમય અટેચમેન્ટ રાખે છે. ફાઇલને વેન્ડર અથવા જાળવનાર આપે તે ખાનગી ચેનલ દ્વારા ખસેડો. જાહેર issue માં કાચો ડમ્પ પોસ્ટ કરવાથી પ્રક્રિયા મરી ત્યારે મેમરીમાં જે હતું તે બધું ખુલ્લું થાય છે, અને કોઈ તપાસે નહીં ત્યાં સુધી તમે જાણી શકતા નથી કે તે શું હતું.

જાળવનાર ટ્રેસ માગે તો પૂછો કે કઈ એક્ઝિક્યુટેબલ અને કઈ લાઇબ્રેરીમાંથી જોઈએ છે. જેની ફ્રેમ્સ અહેવાલિત બિલ્ડ સાથે મેળ ખાતી નથી તેવા backtrace પર ભરોસો કરવો મુશ્કેલ અને ખોટું વાંચવું સહેલું છે.

કંઈપણ બદલતા પહેલાં મૂળ તપાસો

ઇન્સ્ટોલેશનનો માલિક જે છે તેની મારફતે પેકેજનું મૂળ અને ફાઇલની અખંડિતતા ચકાસો, અને કોઈપણ નિયંત્રિત સમારકામ પહેલાં ગોઠવણી અને ઓળખ સામગ્રી સાચવો. ફક્ત એ જોવા માટે પુરાવાની એકમાત્ર નકલ ઉપર ન લખો કે સ્વચ્છ ઇન્સ્ટોલ શરૂ થાય છે કે નહીં. નવી ઇમેજ બૂટ થાય તો કહે છે કે નવી ઇમેજ બૂટ થાય છે. તે કહેતું નથી કે જૂનીમાં ભ્રષ્ટ પેકેજ, નિષ્ફળ થતું કાર્ડ કે એવી બાઇનરી હતી જે આ આર્કિટેક્ચર પર હંમેશા ફોલ્ટ કરત.

અસંબંધિત પ્રોગ્રામ પણ નિષ્ફળ જાય, અથવા સિસ્ટમ સ્ટોરેજ, પાવર કે કર્નલ ભૂલો લોગ કરે, તો તે અવલોકનો પ્લેટફોર્મ તપાસ માટે રાખો. તે અવકાશ વિસ્તારે છે; દરેક segfault નિષ્ફળ RAM કે ભ્રષ્ટ ઇમેજમાંથી આવે છે તે સાબિત કરતા નથી.

લક્ષ્યિત સુધારા પછી તે જ અધિકૃત લોન્ચ અને તે જ VPN કામગીરી તે જ હાર્ડવેર પર પુનરાવર્તિત કરો. કહો કે કઈ નિષ્ફળતા અટકી અને કયા સંસ્કરણ હેઠળ. ફક્ત સ્વચ્છ બૂટ કોઈ ખામીયુક્ત ઘટક ઓળખતું નથી કે આગલી હાર્ડવેર ખામીની આગાહી કરતું નથી.