VPN શરૂ થાય ત્યારે કર્નલ Oops: જાળવી રાખવા લાયક પુરાવા

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

છેલ્લી લાઇન નહીં, પ્રથમ ફોલ્ટ પકડો

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

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

કોઈ પણ પ્રતીક વાંચતા પહેલાં બિલ્ડ નક્કી કરો

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

ટ્રીની બહારના મોડ્યુલો રેકોર્ડમાં પોતાની લાઇનને લાયક છે, કારણ કે taint કરેલું કર્નલ જાળવનારને શું નિષ્કર્ષ કાઢવાની પરવાનગી છે તે મર્યાદિત કરે છે. મોડ્યુલ યાદીમાંથી અનુમાન કરવાને બદલે taint મૂલ્ય વાંચો.

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

ટ્રિગરને ખામીથી અલગ કરો

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

કામ કરતી અગાઉની ઇમેજ પુરાવો છે, પ્રમાણ નહીં. તુલના કરતી વખતે દરેક બૂટમાં એક ઘટક બદલો, અને પરિણામો એવી જગ્યાએ રાખો જે મશીન પછી પણ ટકે.

જાળવનાર ખરેખર શું વાપરી શકે તે તપાસો

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

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

ઉપરની દરેક આજ્ઞા ફક્ત સ્થિતિ વાંચે છે, અને જો મશીન હજી તેમને જવાબ આપી શકે તો પ્રથમ બે આગલા રીબૂટ પહેલાં ચલાવવી જોઈએ. જ્યાં જર્નલ ટકતું નથી, ત્યાં ફક્ત એ બે જ ફરી ક્યારેય કામ કરશે.

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