🥇 ડિબગીંગ સોફ્ટવેર જમાવટ સ્ટ્રેસ સાથે

મારી દિવસની નોકરી મોટે ભાગે સૉફ્ટવેર જમાવટ છે, જેનો અર્થ છે કે હું પ્રશ્નોના જવાબ આપવા માટે ઘણો સમય પસાર કરું છું જેમ કે:

આ સોફ્ટવેર વિકાસકર્તા માટે કામ કરે છે, પરંતુ મારા માટે નહીં. શા માટે?
ગઈકાલે આ સૉફ્ટવેર મારા માટે કામ કરતું હતું, પરંતુ આજે તે નથી કરતું. શા માટે?

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

તેથી તેના બદલે સામાન્ય ડિબગીંગ સાધનો જેવા જીડીબી ડિબગીંગ ડિપ્લોયમેન્ટ માટે મારી પાસે ટૂલ્સનો એક અલગ સેટ છે. અને "આ સોફ્ટવેર મારા માટે કેમ કામ કરતું નથી?" જેવી સમસ્યાનો સામનો કરવા માટેનું મારું પ્રિય સાધન. કહેવાય છે સ્ટ્રેસ.

સ્ટ્રેસ શું છે?

સ્ટ્રેસ "સિસ્ટમ કોલ ટ્રેસીંગ" માટેનું એક સાધન છે. તે મૂળ રૂપે Linux માટે બનાવવામાં આવ્યું હતું, પરંતુ સમાન ડિબગીંગ યુક્તિઓ અન્ય સિસ્ટમો માટે સાધનો સાથે કરી શકાય છે (ડીટ્રેસ અથવા ktrace).

મૂળભૂત એપ્લિકેશન ખૂબ જ સરળ છે. તમારે ફક્ત કોઈપણ આદેશ સાથે સ્ટ્રેસ ચલાવવાની જરૂર છે અને તે તમામ સિસ્ટમ કૉલ્સને ડમ્પ કરશે (જોકે પહેલા તમારે તેને જાતે ઇન્સ્ટોલ કરવું પડશે. સ્ટ્રેસ):

$ strace echo Hello
...Snip lots of stuff...
write(1, "Hellon", 6)                  = 6
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

આ સિસ્ટમ કોલ્સ શું છે? આ ઓપરેટિંગ સિસ્ટમ કર્નલ માટે API જેવું કંઈક છે. એક સમયે, સોફ્ટવેરને તે જે હાર્ડવેર પર ચાલતું હતું તેની સીધી ઍક્સેસ હતી. જો, ઉદાહરણ તરીકે, તેને સ્ક્રીન પર કંઈક પ્રદર્શિત કરવાની જરૂર હોય, તો તે વિડિઓ ઉપકરણો માટે પોર્ટ અથવા મેમરી-મેપ કરેલ રજિસ્ટર સાથે વગાડવામાં આવે છે. જ્યારે મલ્ટીટાસ્કીંગ કોમ્પ્યુટર સિસ્ટમો લોકપ્રિય બની, ત્યારે વિવિધ એપ્લિકેશનો હાર્ડવેર પર લડવાને કારણે અરાજકતાનું શાસન થયું. એક એપ્લિકેશનમાં ભૂલો અન્યને નીચે લાવી શકે છે, જો સમગ્ર સિસ્ટમ નહીં. પછી CPU માં વિશેષાધિકાર મોડ્સ (અથવા "રિંગ પ્રોટેક્શન") દેખાયા. કર્નલ સૌથી વધુ વિશેષાધિકૃત બન્યું: તેને હાર્ડવેરની સંપૂર્ણ ઍક્સેસ પ્રાપ્ત થઈ, ઓછી વિશેષાધિકૃત એપ્લિકેશનો પેદા કરે છે જેને પહેલાથી જ સિસ્ટમ કોલ્સ દ્વારા હાર્ડવેર સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે કર્નલ પાસેથી ઍક્સેસની વિનંતી કરવાની હતી.

દ્વિસંગી સ્તરે, સિસ્ટમ કૉલ સામાન્ય ફંક્શન કૉલ કરતાં થોડો અલગ હોય છે, પરંતુ મોટાભાગના પ્રોગ્રામ્સ પ્રમાણભૂત લાઇબ્રેરીમાં રેપરનો ઉપયોગ કરે છે. તે. POSIX C સ્ટાન્ડર્ડ લાઇબ્રેરીમાં ફંક્શન કૉલ છે લખો (), જે સિસ્ટમ કૉલ માટે તમામ આર્કિટેક્ચર-વિશિષ્ટ કોડ ધરાવે છે લખી.

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

કન્સોલ I/O
નેટવર્ક I/O
ફાઇલ સિસ્ટમ એક્સેસ અને ફાઇલ I/O
પ્રક્રિયા થ્રેડના જીવનકાળનું સંચાલન
લો-લેવલ મેમરી મેનેજમેન્ટ
ચોક્કસ ઉપકરણ ડ્રાઇવરોની ઍક્સેસ

સ્ટ્રેસનો ઉપયોગ ક્યારે કરવો?

સિદ્ધાંત માં, સ્ટ્રેસ યુઝર સ્પેસમાં કોઈપણ પ્રોગ્રામ સાથે ઉપયોગ થાય છે, કારણ કે યુઝર સ્પેસમાં કોઈપણ પ્રોગ્રામે સિસ્ટમ કોલ કરવા જ જોઈએ. તે સંકલિત, નિમ્ન-સ્તરના કાર્યક્રમો સાથે વધુ કાર્યક્ષમ રીતે કાર્ય કરે છે, પરંતુ જો તમે રનટાઈમ અને દુભાષિયાના વધારાના અવાજને કાપી શકો તો તે પાયથોન જેવી ઉચ્ચ-સ્તરની ભાષાઓ સાથે પણ કામ કરે છે.

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

અમે ઉદાહરણ તરીકે સ્ટેન્ડઅલોન સર્વરનો ઉપયોગ કરીશું, પરંતુ સિસ્ટમ કૉલ ટ્રેસિંગ ઘણીવાર વધુ જટિલ ડિપ્લોયમેન્ટ પ્લેટફોર્મ પર કરી શકાય છે. તમારે ફક્ત યોગ્ય સાધનો પસંદ કરવાની જરૂર છે.

સરળ ડીબગીંગ ઉદાહરણ

ચાલો કહીએ કે તમે અદ્ભુત સર્વર એપ્લિકેશન foo ચલાવવા માંગો છો, અને આ તે છે જેની સાથે તમે સમાપ્ત થશો:

$ foo
Error opening configuration file: No such file or directory

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

જો તમારી પાસે સ્રોત કોડની ઍક્સેસ હોય, તો તમે તેને વાંચી શકો છો અને બધું શોધી શકો છો. સારી બેકઅપ યોજના, પરંતુ સૌથી ઝડપી ઉકેલ નથી. તમે સ્ટેપ-બાય-સ્ટેપ ડીબગર જેવા આશરો લઈ શકો છો જીડીબી અને પ્રોગ્રામ શું કરે છે તે જુઓ, પરંતુ તે ટૂલનો ઉપયોગ કરવો વધુ અસરકારક છે જે ખાસ કરીને પર્યાવરણ સાથે ક્રિયાપ્રતિક્રિયા બતાવવા માટે રચાયેલ છે: સ્ટ્રેસ.

નિષ્કર્ષ સ્ટ્રેસ બિનજરૂરી લાગે છે, પરંતુ સારા સમાચાર એ છે કે તેમાંના મોટા ભાગનાને સુરક્ષિત રીતે અવગણી શકાય છે. ટ્રેસ પરિણામોને અલગ ફાઇલમાં સાચવવા માટે -o ઑપરેટરનો ઉપયોગ કરવો ઘણીવાર ઉપયોગી છે:

$ strace -o /tmp/trace foo
Error opening configuration file: No such file or directory
$ cat /tmp/trace
execve("foo", ["foo"], 0x7ffce98dc010 /* 16 vars */) = 0
brk(NULL)                               = 0x56363b3fb000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=25186, ...}) = 0
mmap(NULL, 25186, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2f12cf1000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "177ELF2113 3 > 1 260A2 "..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1824496, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2f12cef000
mmap(NULL, 1837056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2f12b2e000
mprotect(0x7f2f12b50000, 1658880, PROT_NONE) = 0
mmap(0x7f2f12b50000, 1343488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f2f12b50000
mmap(0x7f2f12c98000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16a000) = 0x7f2f12c98000
mmap(0x7f2f12ce5000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b6000) = 0x7f2f12ce5000
mmap(0x7f2f12ceb000, 14336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2f12ceb000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7f2f12cf0500) = 0
mprotect(0x7f2f12ce5000, 16384, PROT_READ) = 0
mprotect(0x56363b08b000, 4096, PROT_READ) = 0
mprotect(0x7f2f12d1f000, 4096, PROT_READ) = 0
munmap(0x7f2f12cf1000, 25186)           = 0
openat(AT_FDCWD, "/etc/foo/config.json", O_RDONLY) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
brk(NULL)                               = 0x56363b3fb000
brk(0x56363b41c000)                     = 0x56363b41c000
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
write(3, "Error opening configuration file"..., 60) = 60
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

આઉટપુટનું લગભગ આખું પ્રથમ પૃષ્ઠ સ્ટ્રેસ - આ સામાન્ય રીતે લોંચ માટે નીચા સ્તરની તૈયારી છે. (ઘણા કોલ્સ mmap, mprotect, ક્વિલ નિમ્ન-સ્તરની મેમરી શોધવા અને ડાયનેમિક લાઇબ્રેરીઓ પ્રદર્શિત કરવા જેવી બાબતો માટે.) ખરેખર, આઉટપુટ ડીબગીંગ દરમિયાન સ્ટ્રેસ ખૂબ જ અંતથી વાંચવું વધુ સારું છે. નીચે એક પડકાર હશે લખી, જે ભૂલ સંદેશ દર્શાવે છે. અમે ઉપર જોઈએ છીએ અને પ્રથમ ભૂલભરેલી સિસ્ટમ કૉલ - કૉલ જુઓ ઓપનેટ, જે ભૂલ ફેંકે છે ENOENT ("ફાઇલ અથવા ડિરેક્ટરી મળી નથી") ખોલવાનો પ્રયાસ કરી રહી છે /etc/foo/config.json. આ તે છે જ્યાં રૂપરેખાંકન ફાઇલ હોવી જોઈએ.

આ માત્ર એક ઉદાહરણ હતું, પરંતુ હું ઉપયોગ કરું છું તે સમયના 90% હું કહીશ સ્ટ્રેસ, આના કરતાં વધુ મુશ્કેલ કંઈ નથી. નીચે એક સંપૂર્ણ પગલું-દર-પગલાં ડિબગીંગ માર્ગદર્શિકા છે:

પ્રોગ્રામમાંથી સિસ્ટમ-વાય ભૂલ વિશે અસ્પષ્ટ સંદેશાને કારણે અસ્વસ્થ થાઓ
સાથે પ્રોગ્રામ પુનઃપ્રારંભ કરો સ્ટ્રેસ
ટ્રેસ પરિણામોમાં ભૂલ સંદેશ શોધો
જ્યાં સુધી તમે પ્રથમ નિષ્ફળ સિસ્ટમ કૉલને હિટ ન કરો ત્યાં સુધી ઉપર જાઓ

તે ખૂબ જ સંભવ છે કે પગલું 4 માં સિસ્ટમ કૉલ શું ખોટું થયું તે જાહેર કરશે.

સંકેતો

તમને વધુ જટિલ ડિબગીંગનું ઉદાહરણ બતાવતા પહેલા, હું તમને અસરકારક ઉપયોગ માટે થોડી યુક્તિઓ બતાવીશ સ્ટ્રેસ:

માણસ તમારો મિત્ર છે

ઘણી *nix સિસ્ટમો પર, કર્નલ પર સિસ્ટમ કૉલ્સની સંપૂર્ણ સૂચિ ચાલીને મેળવી શકાય છે માણસ syscalls. તમે જેવી વસ્તુઓ જોશો brk(2), જેનો અર્થ છે કે વધુ માહિતી ચલાવીને મેળવી શકાય છે માણસ 2 brk.

નાની રેક: માણસ 2 કાંટો મને શેલ માટેનું પૃષ્ઠ બતાવે છે કાંટો () в GNU libc, જે, તે તારણ આપે છે, કૉલ દ્વારા અમલમાં મૂકવામાં આવે છે ક્લોન(). સિમેન્ટિક્સને કૉલ કરો કાંટો જો તમે પ્રોગ્રામનો ઉપયોગ કરીને લખો તો તે જ રહે છે કાંટો (), અને ટ્રેસ ચલાવો - મને કોઈ કૉલ્સ મળશે નહીં કાંટો, તેના બદલે ત્યાં હશે ક્લોન(). જો તમે આઉટપુટ સાથે સ્ત્રોતની સરખામણી કરવાનું શરૂ કરો તો જ આવા રેક્સ તમને મૂંઝવણમાં મૂકે છે સ્ટ્રેસ.

ફાઇલમાં આઉટપુટ સાચવવા માટે -o નો ઉપયોગ કરો

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

વધુ દલીલ ડેટા જોવા માટે -s નો ઉપયોગ કરો

તમે નોંધ્યું હશે કે ભૂલ સંદેશનો બીજો ભાગ ઉપરના ઉદાહરણ ટ્રેસમાં બતાવવામાં આવ્યો નથી. તે કારણ કે સ્ટ્રેસ ડિફૉલ્ટ સ્ટ્રિંગ દલીલના માત્ર પ્રથમ 32 બાઇટ્સ બતાવે છે. જો તમે વધુ જોવા માંગતા હો, તો કંઈક ઉમેરો -સ 128 કૉલ માટે સ્ટ્રેસ.

-y ફાઇલો, સોકેટ્સ વગેરેને ટ્રૅક કરવાનું સરળ બનાવે છે.

"બધું ફાઇલ છે" નો અર્થ છે કે *નિક્સ સિસ્ટમ્સ ફાઇલ વર્ણનકર્તાઓનો ઉપયોગ કરીને તમામ I/O કરે છે, પછી ભલે તે ફાઇલ અથવા નેટવર્ક અથવા ઇન્ટરપ્રોસેસ પાઈપોને લાગુ પડે. આ પ્રોગ્રામિંગ માટે અનુકૂળ છે, પરંતુ જ્યારે તમે સામાન્ય જુઓ ત્યારે ખરેખર શું ચાલી રહ્યું છે તેનો ટ્રૅક રાખવો મુશ્કેલ બનાવે છે વાંચવું и લખી સિસ્ટમ કોલ ટ્રેસ પરિણામોમાં.

ઓપરેટર ઉમેરીને -у, તમે દબાણ કરશો સ્ટ્રેસ આઉટપુટમાં દરેક ફાઇલ વર્ણનકર્તાને તે શું નિર્દેશ કરે છે તેની નોંધ સાથે ટીકા કરો.

-p** સાથે પહેલેથી ચાલી રહેલી પ્રક્રિયા સાથે જોડો

જેમ તમે નીચેના ઉદાહરણમાંથી જોશો, કેટલીકવાર તમારે પહેલાથી ચાલી રહેલ પ્રોગ્રામને ટ્રેસ કરવાની જરૂર છે. જો તે જાણીતું છે કે તે પ્રક્રિયા 1337 તરીકે ચાલી રહ્યું છે (કહો, આઉટપુટમાંથી ps), તો પછી તમે તેને આ રીતે શોધી શકો છો:

$ strace -p 1337
...system call trace output...

તમને રૂટ અધિકારોની જરૂર પડી શકે છે.

બાળ પ્રક્રિયાઓ પર દેખરેખ રાખવા માટે -f નો ઉપયોગ કરો

સ્ટ્રેસ મૂળભૂત રીતે, તે માત્ર એક પ્રક્રિયાને ટ્રેસ કરે છે. જો આ પ્રક્રિયા બાળ પ્રક્રિયાઓને જન્મ આપે છે, તો પછી બાળ પ્રક્રિયાને ફેલાવવા માટેનો સિસ્ટમ કૉલ જોઈ શકાય છે, પરંતુ બાળ પ્રક્રિયાના સિસ્ટમ કૉલ્સ પ્રદર્શિત થશે નહીં.

જો તમને લાગે કે ભૂલ બાળ પ્રક્રિયામાં છે, તો નિવેદનનો ઉપયોગ કરો -f, આ તેના ટ્રેસિંગને સક્ષમ કરશે. આનું નુકસાન એ છે કે આઉટપુટ તમને વધુ મૂંઝવણમાં મૂકશે. ક્યારે સ્ટ્રેસ એક પ્રક્રિયા અથવા એક થ્રેડને ટ્રેસ કરે છે, તે કૉલ ઇવેન્ટ્સની એક સ્ટ્રીમ બતાવે છે. જ્યારે તે એકસાથે અનેક પ્રક્રિયાઓને ટ્રેસ કરે છે, ત્યારે તમે સંદેશ દ્વારા વિક્ષેપિત કૉલની શરૂઆત જોઈ શકો છો , પછી - અન્ય એક્ઝેક્યુશન શાખાઓ માટે કૉલ્સનો સમૂહ, અને તે પછી જ - પ્રથમનો અંત . અથવા ઓપરેટરનો ઉપયોગ કરીને તમામ ટ્રેસ પરિણામોને વિવિધ ફાઇલોમાં વિભાજિત કરો -ff (માં વિગતો નેતૃત્વ પર સ્ટ્રેસ).

-e નો ઉપયોગ કરીને નિશાનો ફિલ્ટર કરો

જેમ તમે જોઈ શકો છો, ટ્રેસનું પરિણામ એ તમામ સંભવિત સિસ્ટમ કૉલ્સનો વાસ્તવિક ખૂંટો છે. ધ્વજ -e તમે ટ્રેસ ફિલ્ટર કરી શકો છો (જુઓ નેતૃત્વ પર સ્ટ્રેસ). મુખ્ય ફાયદો એ છે કે સંપૂર્ણ ટ્રેસ કરવા કરતાં ફિલ્ટર કરેલ ટ્રેસ ચલાવવાનું ઝડપી છે અને પછી grep`એટ. સાચું કહું તો, હું લગભગ હંમેશા કાળજી રાખતો નથી.

બધી ભૂલો ખરાબ નથી હોતી

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

$ strace sh -c uname
...
stat("/home/user/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/bin/uname", {st_mode=S_IFREG|0755, st_size=39584, ...}) = 0
...

"ભૂલની જાણ કરતા પહેલા છેલ્લી નિષ્ફળ વિનંતી" જેવી હ્યુરિસ્ટિક્સ સંબંધિત ભૂલો શોધવામાં સારી છે. ભલે તે બની શકે, તે ખૂબ જ અંતથી શરૂ કરવું તાર્કિક છે.

સી પ્રોગ્રામિંગ ટ્યુટોરિયલ્સ તમને સિસ્ટમ કોલ્સ સમજવામાં મદદ કરી શકે છે.

C લાઇબ્રેરીઓ માટે માનક કૉલ્સ એ સિસ્ટમ કૉલ્સ નથી, પરંતુ માત્ર એક પાતળા સપાટી સ્તર છે. તેથી, જો તમે ઓછામાં ઓછું થોડું સમજો છો કે C માં કેવી રીતે અને શું કરવું, તો તમારા માટે સિસ્ટમ કૉલ ટ્રેસના પરિણામોને સમજવું સરળ બનશે. ઉદાહરણ તરીકે, તમને નેટવર્ક સિસ્ટમ્સ પર કૉલ ડિબગ કરવામાં સમસ્યા છે, તે જ ક્લાસિક જુઓ નેટવર્ક પ્રોગ્રામિંગ માટે બિજાની માર્ગદર્શિકા.

વધુ જટિલ ડીબગીંગ ઉદાહરણ

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

bcron - ટાસ્ક પ્રોસેસિંગ શેડ્યૂલર, *નિક્સ ડિમનનું બીજું અમલીકરણ ક્રોન. તે સર્વર પર ઇન્સ્ટોલ કરેલું છે, પરંતુ જ્યારે કોઈ વ્યક્તિ શેડ્યૂલને સંપાદિત કરવાનો પ્રયાસ કરે છે, ત્યારે આ થાય છે:

# crontab -e -u logs
bcrontab: Fatal: Could not create temporary file

ઠીક છે, તેનો અર્થ છે bcron ચોક્કસ ફાઇલ લખવાનો પ્રયાસ કર્યો, પરંતુ તે કામ ન કર્યું, અને તે શા માટે સ્વીકારશે નહીં. અનકવરિંગ સ્ટ્રેસ:

# strace -o /tmp/trace crontab -e -u logs
bcrontab: Fatal: Could not create temporary file
# cat /tmp/trace
...
openat(AT_FDCWD, "bcrontab.14779.1573691864.847933", O_RDONLY) = 3
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
read(3, "#Ansible: logsaggn20 14 * * * lo"..., 8192) = 150
read(3, "", 8192)                       = 0
munmap(0x7f82049b4000, 8192)            = 0
close(3)                                = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/bcron-spool"}, 110) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
write(3, "156:Slogs #Ansible: logsaggn20 1"..., 161) = 161
read(3, "32:ZCould not create temporary f"..., 8192) = 36
munmap(0x7f82049b4000, 8192)            = 0
close(3)                                = 0
write(2, "bcrontab: Fatal: Could not creat"..., 49) = 49
unlink("bcrontab.14779.1573691864.847933") = 0
exit_group(111)                         = ?
+++ exited with 111 +++

ખૂબ જ અંતની નજીક એક ભૂલ સંદેશ છે લખી, પરંતુ આ વખતે કંઈક અલગ છે. પ્રથમ, ત્યાં કોઈ સંબંધિત સિસ્ટમ કૉલ ભૂલ નથી, જે સામાન્ય રીતે આ પહેલાં થાય છે. બીજું, તે સ્પષ્ટ છે કે ક્યાંક કોઈએ પહેલેથી જ ભૂલ સંદેશ વાંચ્યો છે. એવું લાગે છે કે વાસ્તવિક સમસ્યા બીજે ક્યાંક છે, અને bcrontab ખાલી મેસેજને પ્લે કરે છે.

જો તમે જુઓ માણસ 2 વાંચો, તમે જોઈ શકો છો કે પ્રથમ દલીલ (3) ફાઇલ વર્ણનકર્તા છે, જે *nix તમામ I/O પ્રક્રિયા માટે વાપરે છે. હું કેવી રીતે શોધી શકું કે ફાઇલ ડિસ્ક્રિપ્ટર 3 શું રજૂ કરે છે? આ ચોક્કસ કિસ્સામાં, તમે ચલાવી શકો છો સ્ટ્રેસ ઓપરેટર સાથે -у (ઉપર જુઓ) અને તે તમને આપમેળે કહેશે, પરંતુ આના જેવી સામગ્રીને સમજવા માટે, ટ્રેસ પરિણામોને કેવી રીતે વાંચવું અને તેનું વિશ્લેષણ કરવું તે જાણવું ઉપયોગી છે.

ફાઇલ ડિસ્ક્રિપ્ટરનો સ્ત્રોત ઘણા સિસ્ટમ કૉલ્સમાંથી એક હોઈ શકે છે (તે બધું તેના પર નિર્ભર કરે છે કે વર્ણનકર્તા શેના માટે છે - કન્સોલ, નેટવર્ક સોકેટ, ફાઇલ પોતે, અથવા બીજું કંઈક), પરંતુ તે ગમે તે હોય, અમે તેને શોધીએ છીએ. 3 પરત કરીને કૉલ કરો (એટલે કે અમે ટ્રેસિંગ પરિણામોમાં “= 3” શોધીએ છીએ). આ પરિણામમાં તેમાંના 2 છે: ઓપનેટ ખૂબ જ ટોચ પર અને સોકેટ વચ્ચે. ઓપનેટ ફાઇલ ખોલે છે પરંતુ બંધ(3) પછી બતાવશે કે તે ફરીથી બંધ થાય છે. (રેક: ફાઇલ ડિસ્ક્રીપ્ટર્સ જ્યારે ખોલવામાં આવે અને બંધ થાય ત્યારે તેનો ફરીથી ઉપયોગ કરી શકાય છે). કૉલ કરો સોકેટ() યોગ્ય છે કારણ કે તે પહેલાનું છેલ્લું છે વાંચવું(), અને તે તારણ આપે છે કે bcrontab સોકેટ દ્વારા કંઈક સાથે કામ કરે છે. આગળની લાઇન બતાવે છે કે ફાઇલ વર્ણનકર્તા સાથે સંકળાયેલ છે યુનિક્સ ડોમેન સોકેટ રસ્તામા /var/run/bcron-sool.

તેથી, આપણે તેની સાથે સંકળાયેલ પ્રક્રિયા શોધવાની જરૂર છે યુનિક્સ સોકેટ બીજી બાજુ પર. આ હેતુ માટે કેટલીક સુઘડ યુક્તિઓ છે, જે બંને સર્વર જમાવટને ડીબગ કરવા માટે ઉપયોગી છે. પ્રથમ ઉપયોગ કરવાનો છે નેટસ્ટેટ અથવા વધુ નવું ss (સોકેટ સ્થિતિ). બંને આદેશો સિસ્ટમના સક્રિય નેટવર્ક જોડાણો દર્શાવે છે અને નિવેદન લે છે -l સાંભળવાના સોકેટ્સ, તેમજ ઓપરેટરનું વર્ણન કરવા માટે -p ક્લાયન્ટ તરીકે સોકેટ સાથે જોડાયેલા પ્રોગ્રામ્સ પ્રદર્શિત કરવા માટે. (ત્યાં ઘણા વધુ ઉપયોગી વિકલ્પો છે, પરંતુ આ બે આ કાર્ય માટે પૂરતા છે.)

# ss -pl | grep /var/run/bcron-spool
u_str LISTEN 0   128   /var/run/bcron-spool 1466637   * 0   users:(("unixserver",pid=20629,fd=3))

આ સૂચવે છે કે સાંભળનાર આદેશ છે inixserver, પ્રોસેસ આઈડી 20629 સાથે ચાલી રહ્યું છે. (અને, સંયોગથી, તે સોકેટ તરીકે ફાઈલ ડિસ્ક્રીપ્ટર 3 નો ઉપયોગ કરે છે.)

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

# lsof /var/run/bcron-spool
COMMAND   PID   USER  FD  TYPE  DEVICE              SIZE/OFF  NODE    NAME
unixserve 20629 cron  3u  unix  0x000000005ac4bd83  0t0       1466637 /var/run/bcron-spool type=STREAM

પ્રક્રિયા 20629 એ લાંબા સમય સુધી ચાલતું સર્વર છે, તેથી તમે તેને જોડી શકો છો સ્ટ્રેસ કંઈક ઉપયોગ કરીને strace -o /tmp/trace -p 20629. જો તમે બીજા ટર્મિનલમાં ક્રોન જોબ એડિટ કરો છો, તો તમને ભૂલ સાથે ટ્રેસ આઉટપુટ મળશે. અને અહીં પરિણામ છે:

accept(3, NULL, NULL)                   = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21181
close(4)                                = 0
accept(3, NULL, NULL)                   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21181, si_uid=998, si_status=0, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED, NULL) = 21181
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]})                 = 43
accept(3, NULL, NULL)                   = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21200
close(4)                                = 0
accept(3, NULL, NULL)                   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21200, si_uid=998, si_status=111, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 111}], WNOHANG|WSTOPPED, NULL) = 21200
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]})                 = 43
accept(3, NULL, NULL

(છેલ્લા સ્વીકારો() ટ્રેસ કરતી વખતે પૂર્ણ કરવામાં આવશે નહીં.) ફરીથી, કમનસીબે, આ પરિણામમાં અમે શોધી રહ્યા છીએ તે ભૂલ શામેલ નથી. અમને કોઈ સંદેશા દેખાતા નથી કે જે bcrontag સોકેટને મોકલે છે અથવા પ્રાપ્ત કરે છે. તેના બદલે, સંપૂર્ણ પ્રક્રિયા નિયંત્રણ (ક્લોન, રાહ જુઓ4, SIGCHLD વગેરે.) આ પ્રક્રિયા બાળ પ્રક્રિયાને જન્મ આપે છે, જે તમે ધારી શકો છો, વાસ્તવિક કાર્ય કરે છે. અને જો તમારે તેનું પગેરું પકડવું હોય, તો કૉલમાં ઉમેરો strace -f. જ્યારે આપણે નવા પરિણામમાં સ્ટ્રેસ સાથે એરર મેસેજ શોધીશું ત્યારે આ આપણને મળશે -f -o /tmp/trace -p 20629:

21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111)                   = ?
21470 +++ exited with 111 +++

હવે, તે કંઈક છે. પ્રક્રિયા 21470 પાથ પર ફાઇલ બનાવવાનો પ્રયાસ કરતી વખતે "ઍક્સેસ નકારેલ" ભૂલ પ્રાપ્ત કરે છે tmp/sool.21470.1573692319.854640 (વર્તમાન કાર્યકારી નિર્દેશિકા સાથે સંબંધિત). જો આપણે વર્તમાન કાર્યકારી નિર્દેશિકા જાણતા હોઈએ, તો અમે સંપૂર્ણ પાથ પણ જાણતા હોઈશું અને પ્રક્રિયા શા માટે તેની અસ્થાયી ફાઇલ તેમાં બનાવી શકતી નથી તે સમજવામાં સક્ષમ થઈશું. કમનસીબે, પ્રક્રિયા પહેલાથી જ બહાર નીકળી ગઈ છે, તેથી તમે ફક્ત ઉપયોગ કરી શકતા નથી lsof -p 21470 વર્તમાન ડિરેક્ટરી શોધવા માટે, પરંતુ તમે વિરુદ્ધ દિશામાં કામ કરી શકો છો - PID 21470 સિસ્ટમ કૉલ્સ જુઓ જે ડિરેક્ટરીને બદલે છે. (જો ત્યાં કોઈ ન હોય, તો PID 21470 એ તેને તેના માતાપિતા પાસેથી વારસામાં મેળવ્યું હોવું જોઈએ, અને તે પહેલાથી જ છે. lsof -p શોધી શકાતું નથી.) આ સિસ્ટમ કોલ છે chdir (જે આધુનિક ઓનલાઈન સર્ચ એન્જિનની મદદથી શોધવામાં સરળ છે). અને સર્વર PID 20629 સુધીના તમામ રીતે ટ્રેસ પરિણામોના આધારે વિપરીત શોધોનું પરિણામ અહીં છે:

20629 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21470
...
21470 execve("/usr/sbin/bcron-spool", ["bcron-spool"], 0x55d2460807e0 /* 27 vars */) = 0
...
21470 chdir("/var/spool/cron")          = 0
...
21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111)                   = ?
21470 +++ exited with 111 +++

(જો તમે ખોવાઈ ગયા હો, તો તમે કદાચ મારી અગાઉની પોસ્ટ વાંચવા માગો છો *નિક્સ પ્રોસેસ મેનેજમેન્ટ અને શેલ્સ વિશેતેથી, સર્વર PID 20629 ને પાથ પર ફાઇલ બનાવવાની પરવાનગી મળી નથી. /var/sool/cron/tmp/sool.21470.1573692319.854640. મોટે ભાગે, આનું કારણ ક્લાસિક ફાઇલ સિસ્ટમ પરવાનગી સેટિંગ્સ છે. ચાલો તપાસીએ:

# ls -ld /var/spool/cron/tmp/
drwxr-xr-x 2 root root 4096 Nov  6 05:33 /var/spool/cron/tmp/
# ps u -p 20629
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cron     20629  0.0  0.0   2276   752 ?        Ss   Nov14   0:00 unixserver -U /var/run/bcron-spool -- bcron-spool

ત્યાં જ કૂતરાને દફનાવવામાં આવે છે! સર્વર વપરાશકર્તા ક્રોન તરીકે ચાલે છે, પરંતુ માત્ર રૂટને જ ડિરેક્ટરીમાં લખવાની પરવાનગી છે /var/sool/cron/tmp/. સરળ આદેશ ચાઉન ક્રોન /var/સ્પૂલ/ક્રોન/tmp/ દબાણ કરશે bcron યોગ્ય રીતે કામ કરો. (જો તે સમસ્યા ન હતી, તો પછીની સંભવિત શંકા એ SELinux અથવા AppArmor જેવા કર્નલ સુરક્ષા મોડ્યુલ છે, તેથી હું કર્નલ સંદેશ લોગને તેની સાથે તપાસીશ. dmesg.)

કુલ

સિસ્ટમ કૉલ ટ્રેસ શિખાઉ માણસ માટે જબરજસ્ત હોઈ શકે છે, પરંતુ મને આશા છે કે મેં બતાવ્યું છે કે તે સામાન્ય જમાવટ સમસ્યાઓના સંપૂર્ણ વર્ગને ડીબગ કરવાની ઝડપી રીત છે. મલ્ટીપ્રોસેસને ડીબગ કરવાનો પ્રયાસ કરવાની કલ્પના કરો bcronસ્ટેપ-બાય-સ્ટેપ ડીબગરનો ઉપયોગ કરીને.

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

સોર્સ: www.habr.com

સ્ટ્રેસ સાથે ડીબગીંગ સોફ્ટવેર જમાવટ

સ્ટ્રેસ શું છે?

સ્ટ્રેસનો ઉપયોગ ક્યારે કરવો?

સરળ ડીબગીંગ ઉદાહરણ

સંકેતો

વધુ જટિલ ડીબગીંગ ઉદાહરણ

કુલ

એક ટિપ્પણી ઉમેરો જવાબ રદ