സ്‌ട്രേസ് ഉപയോഗിച്ച് ഡീബഗ്ഗിംഗ് സോഫ്‌റ്റ്‌വെയർ വിന്യാസം

എന്റെ ദൈനംദിന ജോലി കൂടുതലും സോഫ്‌റ്റ്‌വെയർ വിന്യാസമാണ്, അതായത് ഇനിപ്പറയുന്നതുപോലുള്ള ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകാൻ ഞാൻ ധാരാളം സമയം ചെലവഴിക്കുന്നു:

• ഈ സോഫ്റ്റ്‌വെയർ ഡെവലപ്പർക്ക് വേണ്ടി പ്രവർത്തിക്കുന്നു, പക്ഷേ എനിക്കല്ല. എന്തുകൊണ്ട്?
• ഇന്നലെ ഈ സോഫ്റ്റ്‌വെയർ എനിക്ക് വേണ്ടി പ്രവർത്തിച്ചു, എന്നാൽ ഇന്ന് അത് പ്രവർത്തിക്കുന്നില്ല. എന്തുകൊണ്ട്?

സാധാരണ സോഫ്‌റ്റ്‌വെയർ ഡീബഗ്ഗിംഗിൽ നിന്ന് അല്പം വ്യത്യസ്തമായ ഒരു തരം ഡീബഗ്ഗിംഗ് ആണിത്. റെഗുലർ ഡീബഗ്ഗിംഗ് എന്നത് കോഡിന്റെ യുക്തിയെക്കുറിച്ചാണ്, എന്നാൽ വിന്യാസ ഡീബഗ്ഗിംഗ് എന്നത് കോഡും പരിസ്ഥിതിയും തമ്മിലുള്ള പ്രതിപ്രവർത്തനത്തെക്കുറിച്ചാണ്. പ്രശ്‌നത്തിന്റെ മൂലകാരണം ഒരു ലോജിക്കൽ പിശകാണെങ്കിൽ പോലും, എല്ലാം ഒരു മെഷീനിൽ പ്രവർത്തിക്കുന്നു, മറ്റൊന്നിൽ പ്രവർത്തിക്കുന്നില്ല എന്നതിന്റെ അർത്ഥം പ്രശ്നം എങ്ങനെയെങ്കിലും പരിസ്ഥിതിയിലാണെന്നാണ്.

അതിനാൽ സാധാരണ ഡീബഗ്ഗിംഗ് ടൂളുകൾക്ക് പകരം ജിഡിബി ഡീബഗ്ഗിംഗ് വിന്യാസത്തിനായി എനിക്ക് മറ്റൊരു കൂട്ടം ടൂളുകൾ ഉണ്ട്. "എന്തുകൊണ്ടാണ് ഈ സോഫ്‌റ്റ്‌വെയർ എനിക്ക് പ്രവർത്തിക്കാത്തത്?" എന്നതുപോലുള്ള പ്രശ്‌നം കൈകാര്യം ചെയ്യുന്നതിനുള്ള എന്റെ പ്രിയപ്പെട്ട ഉപകരണം. വിളിച്ചു സ്ട്രെയ്സ്.

എന്താണ് സ്‌ട്രേസ്?

സ്ട്രെയ്സ് "സിസ്റ്റം കോൾ ട്രേസിംഗ്" എന്നതിനുള്ള ഒരു ഉപകരണമാണ്. ഇത് യഥാർത്ഥത്തിൽ ലിനക്സിനായി സൃഷ്ടിച്ചതാണ്, എന്നാൽ മറ്റ് സിസ്റ്റങ്ങൾക്കുള്ള ടൂളുകൾ ഉപയോഗിച്ച് അതേ ഡീബഗ്ഗിംഗ് തന്ത്രങ്ങൾ ചെയ്യാൻ കഴിയും (ഡിട്രേസ് അഥവാ 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 പോലെയാണ്. ഒരു കാലത്ത്, സോഫ്റ്റ്‌വെയറിന് അത് പ്രവർത്തിപ്പിക്കുന്ന ഹാർഡ്‌വെയറിലേക്ക് നേരിട്ട് പ്രവേശനം ഉണ്ടായിരുന്നു. ഉദാഹരണത്തിന്, സ്ക്രീനിൽ എന്തെങ്കിലും പ്രദർശിപ്പിക്കണമെങ്കിൽ, അത് പോർട്ടുകൾ അല്ലെങ്കിൽ വീഡിയോ ഉപകരണങ്ങൾക്കായി മെമ്മറി-മാപ്പ് ചെയ്ത രജിസ്റ്ററുകൾ ഉപയോഗിച്ച് പ്ലേ ചെയ്യുന്നു. മൾട്ടിടാസ്‌കിംഗ് കമ്പ്യൂട്ടർ സംവിധാനങ്ങൾ പ്രചാരത്തിലായപ്പോൾ, ഹാർഡ്‌വെയറുമായി ബന്ധപ്പെട്ട് വിവിധ ആപ്ലിക്കേഷനുകൾ പോരാടിയതിനാൽ കുഴപ്പങ്ങൾ ഭരിച്ചു. ഒരു ആപ്ലിക്കേഷനിലെ പിഴവുകൾ മുഴുവൻ സിസ്റ്റത്തെയും അല്ലെങ്കിലും മറ്റുള്ളവയെ തകർക്കും. തുടർന്ന് പ്രിവിലേജ് മോഡുകൾ (അല്ലെങ്കിൽ "റിംഗ് പ്രൊട്ടക്ഷൻ") സിപിയുവിൽ പ്രത്യക്ഷപ്പെട്ടു. കേർണൽ ഏറ്റവും പ്രിവിലേജായി മാറി: ഇതിന് ഹാർഡ്‌വെയറിലേക്ക് പൂർണ്ണ ആക്‌സസ് ലഭിച്ചു, സിസ്റ്റം കോളുകൾ വഴി ഹാർഡ്‌വെയറുമായി സംവദിക്കുന്നതിന് കേർണലിൽ നിന്ന് ആക്‌സസ്സ് അഭ്യർത്ഥിക്കേണ്ടി വരുന്ന പ്രത്യേകാവകാശമില്ലാത്ത ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിച്ചു.

ബൈനറി തലത്തിൽ, ഒരു സിസ്റ്റം കോൾ ഒരു ലളിതമായ ഫംഗ്ഷൻ കോളിൽ നിന്ന് അല്പം വ്യത്യസ്തമാണ്, എന്നാൽ മിക്ക പ്രോഗ്രാമുകളും സ്റ്റാൻഡേർഡ് ലൈബ്രറിയിൽ ഒരു റാപ്പർ ഉപയോഗിക്കുന്നു. ആ. POSIX C സ്റ്റാൻഡേർഡ് ലൈബ്രറിയിൽ ഒരു ഫംഗ്‌ഷൻ കോൾ അടങ്ങിയിരിക്കുന്നു എഴുതുക (), സിസ്റ്റം കോളിനുള്ള എല്ലാ ആർക്കിടെക്ചർ-നിർദ്ദിഷ്ട കോഡുകളും ഇതിൽ അടങ്ങിയിരിക്കുന്നു എഴുതുക.

ചുരുക്കത്തിൽ, ഒരു ആപ്ലിക്കേഷനും അതിന്റെ പരിസ്ഥിതിയും (കമ്പ്യൂട്ടർ സിസ്റ്റങ്ങൾ) തമ്മിലുള്ള ഏതൊരു ഇടപെടലും സിസ്റ്റം കോളുകളിലൂടെയാണ് നടത്തുന്നത്. അതിനാൽ, സോഫ്റ്റ്‌വെയർ ഒരു മെഷീനിൽ പ്രവർത്തിക്കുമ്പോൾ മറ്റൊന്നിൽ അല്ല, സിസ്റ്റം കോൾ ട്രെയ്‌സിംഗ് ഫലങ്ങൾ നോക്കുന്നത് നന്നായിരിക്കും. കൂടുതൽ വ്യക്തമായി പറഞ്ഞാൽ, സിസ്റ്റം കോൾ ട്രെയ്സ് ഉപയോഗിച്ച് വിശകലനം ചെയ്യാൻ കഴിയുന്ന സാധാരണ പോയിന്റുകളുടെ ഒരു ലിസ്റ്റ് ഇതാ:

• കൺസോൾ I/O
• നെറ്റ്‌വർക്ക് I/O
• ഫയൽ സിസ്റ്റം ആക്സസും ഫയൽ I/O
• ഒരു പ്രോസസ്സ് ത്രെഡിന്റെ ആയുസ്സ് നിയന്ത്രിക്കുന്നു
• ലോ-ലെവൽ മെമ്മറി മാനേജ്മെന്റ്
• നിർദ്ദിഷ്ട ഉപകരണ ഡ്രൈവറുകളിലേക്കുള്ള ആക്സസ്

എപ്പോഴാണ് സ്‌ട്രേസ് ഉപയോഗിക്കേണ്ടത്?

സിദ്ധാന്തത്തിൽ, സ്ട്രെയ്സ് ഉപയോക്തൃ സ്ഥലത്ത് ഏത് പ്രോഗ്രാമിലും ഉപയോഗിക്കുന്നു, കാരണം ഉപയോക്തൃ സ്ഥലത്ത് ഏത് പ്രോഗ്രാമും സിസ്റ്റം കോളുകൾ ചെയ്യണം. കംപൈൽ ചെയ്‌ത, ലോ-ലെവൽ പ്രോഗ്രാമുകളിൽ ഇത് കൂടുതൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കുന്നു, എന്നാൽ റൺടൈമിൽ നിന്നും ഇന്റർപ്രെറ്ററിൽ നിന്നുമുള്ള അധിക ശബ്‌ദം കുറയ്ക്കാൻ നിങ്ങൾക്ക് കഴിയുമെങ്കിൽ പൈത്തൺ പോലുള്ള ഉയർന്ന തലത്തിലുള്ള ഭാഷകളിലും ഇത് പ്രവർത്തിക്കുന്നു.

അതിന്റെ എല്ലാ മഹത്വത്തിലും സ്ട്രെയ്സ് ഒരു മെഷീനിൽ നന്നായി പ്രവർത്തിക്കുന്ന സോഫ്‌റ്റ്‌വെയറിന്റെ ഡീബഗ്ഗിംഗ് സമയത്ത് സ്വയം പ്രത്യക്ഷപ്പെടുന്നു, പക്ഷേ മറ്റൊന്നിൽ പെട്ടെന്ന് പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു, ഫയലുകൾ, അനുമതികൾ, അല്ലെങ്കിൽ ചില കമാൻഡുകൾ അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും എക്സിക്യൂട്ട് ചെയ്യാനുള്ള പരാജയപ്പെട്ട ശ്രമങ്ങൾ എന്നിവയെക്കുറിച്ചുള്ള അവ്യക്തമായ സന്ദേശങ്ങൾ സൃഷ്ടിക്കുന്നു... ഇത് ഖേദകരമാണ്, പക്ഷേ അങ്ങനെയല്ല സർട്ടിഫിക്കറ്റ് പരിശോധന പിശകുകൾ പോലുള്ള ഉയർന്ന തലത്തിലുള്ള പ്രശ്നങ്ങളുമായി നന്നായി സംയോജിപ്പിക്കുക. സാധാരണയായി ഇതിന് ഒരു കോമ്പിനേഷൻ ആവശ്യമാണ് സ്ട്രെയ്സ്ചിലപ്പോൾ കണ്ടെത്തുക ഉയർന്ന ലെവൽ ടൂളുകളും (കമാൻഡ് ലൈൻ ടൂൾ പോലെ openssl സർട്ടിഫിക്കറ്റ് ഡീബഗ് ചെയ്യാൻ).

ഞങ്ങൾ ഒരു ഒറ്റപ്പെട്ട സെർവർ ഉദാഹരണമായി ഉപയോഗിക്കും, എന്നാൽ കൂടുതൽ സങ്കീർണ്ണമായ വിന്യാസ പ്ലാറ്റ്‌ഫോമുകളിൽ സിസ്റ്റം കോൾ ട്രെയ്‌സിംഗ് പലപ്പോഴും ചെയ്യാൻ കഴിയും. നിങ്ങൾ ശരിയായ ഉപകരണങ്ങൾ തിരഞ്ഞെടുക്കേണ്ടതുണ്ട്.

ലളിതമായ ഡീബഗ്ഗിംഗ് ഉദാഹരണം

അതിശയകരമായ സെർവർ ആപ്ലിക്കേഷൻ ഫൂ പ്രവർത്തിപ്പിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് പറയാം, ഇതാണ് നിങ്ങൾ അവസാനിക്കുന്നത്:

$ 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, സംരക്ഷിക്കുക, brk ലോ-ലെവൽ മെമ്മറി കണ്ടെത്തുന്നതും ഡൈനാമിക് ലൈബ്രറികൾ പ്രദർശിപ്പിക്കുന്നതും പോലുള്ള കാര്യങ്ങൾക്ക്.) യഥാർത്ഥത്തിൽ, ഔട്ട്പുട്ട് ഡീബഗ്ഗിംഗ് സമയത്ത് സ്ട്രെയ്സ് അവസാനം മുതൽ വായിക്കുന്നതാണ് നല്ലത്. താഴെ ഒരു വെല്ലുവിളി ഉണ്ടാകും എഴുതുക, ഒരു പിശക് സന്ദേശം പ്രദർശിപ്പിക്കുന്നു. ഞങ്ങൾ മുകളിൽ നോക്കുകയും ആദ്യത്തെ തെറ്റായ സിസ്റ്റം കോൾ കാണുകയും ചെയ്യുന്നു - കോൾ തുറക്കുക, ഒരു പിശക് എറിയുന്നു ENOENT (“ഫയലോ ഡയറക്ടറിയോ കണ്ടെത്തിയില്ല”) തുറക്കാൻ ശ്രമിക്കുന്നു /etc/foo/config.json. ഇവിടെയാണ് കോൺഫിഗറേഷൻ ഫയൽ ഉണ്ടായിരിക്കേണ്ടത്.

ഇതൊരു ഉദാഹരണം മാത്രമായിരുന്നു, എന്നാൽ ഞാൻ ഉപയോഗിക്കുന്ന സമയത്തിന്റെ 90% ഞാൻ പറയും സ്ട്രെയ്സ്, ഇതിനേക്കാൾ ബുദ്ധിമുട്ടുള്ള മറ്റൊന്നും ചെയ്യാനില്ല. ഒരു പൂർണ്ണമായ ഘട്ടം ഘട്ടമായുള്ള ഡീബഗ്ഗിംഗ് ഗൈഡ് ചുവടെയുണ്ട്:

• ഒരു പ്രോഗ്രാമിൽ നിന്നുള്ള സിസ്റ്റം-വൈ പിശകിനെക്കുറിച്ചുള്ള അവ്യക്തമായ സന്ദേശം കാരണം അസ്വസ്ഥരാകുക
• ഉപയോഗിച്ച് പ്രോഗ്രാം പുനരാരംഭിക്കുക സ്ട്രെയ്സ്
• ട്രേസ് ഫലങ്ങളിൽ പിശക് സന്ദേശം കണ്ടെത്തുക
• പരാജയപ്പെട്ട ആദ്യത്തെ സിസ്റ്റം കോൾ അടിക്കുന്നത് വരെ ഉയരത്തിലേക്ക് പോകുക

ഘട്ടം 4-ലെ സിസ്റ്റം കോൾ എന്താണ് തെറ്റ് സംഭവിച്ചതെന്ന് വെളിപ്പെടുത്താൻ സാധ്യതയുണ്ട്.

സൂചനകൾ

കൂടുതൽ സങ്കീർണ്ണമായ ഡീബഗ്ഗിംഗിന്റെ ഒരു ഉദാഹരണം കാണിക്കുന്നതിന് മുമ്പ്, ഫലപ്രദമായ ഉപയോഗത്തിനായി ഞാൻ കുറച്ച് തന്ത്രങ്ങൾ കാണിക്കും സ്ട്രെയ്സ്:

മനുഷ്യൻ നിങ്ങളുടെ സുഹൃത്താണ്

പല *nix സിസ്റ്റങ്ങളിലും, കേർണലിലേക്കുള്ള സിസ്റ്റം കോളുകളുടെ പൂർണ്ണമായ ലിസ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ ലഭിക്കും മനുഷ്യൻ syscalls. തുടങ്ങിയ കാര്യങ്ങൾ നിങ്ങൾ കാണും brk(2), അതായത് പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ കൂടുതൽ വിവരങ്ങൾ ലഭിക്കും മനുഷ്യൻ 2 ബ്രേക്ക്.

ചെറിയ റേക്ക്: മനുഷ്യൻ 2 ഫോർക്ക് ഷെല്ലിനുള്ള പേജ് എന്നെ കാണിക്കുന്നു ഫോർക്ക് () в GNU libc, ഏത്, അത് മാറുന്നു, വിളിച്ച് നടപ്പിലാക്കുന്നത് ക്ലോൺ(). സെമാന്റിക്സിനെ വിളിക്കുക ഫോർക്ക് നിങ്ങൾ ഒരു പ്രോഗ്രാം എഴുതുകയാണെങ്കിൽ അതേപടി നിലനിൽക്കും ഫോർക്ക് (), ഒരു ട്രെയ്സ് പ്രവർത്തിപ്പിക്കുക - ഞാൻ കോളുകളൊന്നും കണ്ടെത്തുകയില്ല ഫോർക്ക്, അവയ്ക്ക് പകരം ഉണ്ടാകും ക്ലോൺ(). നിങ്ങൾ ഉറവിടത്തെ ഔട്ട്പുട്ടുമായി താരതമ്യം ചെയ്യാൻ തുടങ്ങിയാൽ അത്തരം റേക്കുകൾ നിങ്ങളെ ആശയക്കുഴപ്പത്തിലാക്കുന്നു സ്ട്രെയ്സ്.

ഒരു ഫയലിലേക്ക് ഔട്ട്പുട്ട് സംരക്ഷിക്കാൻ -o ഉപയോഗിക്കുക

സ്ട്രെയ്സ് വിപുലമായ ഔട്ട്‌പുട്ട് സൃഷ്ടിക്കാൻ കഴിയും, അതിനാൽ ട്രെയ്സ് ഫലങ്ങൾ പ്രത്യേക ഫയലുകളിൽ സംഭരിക്കുന്നത് പലപ്പോഴും ഉപയോഗപ്രദമാണ് (മുകളിലുള്ള ഉദാഹരണത്തിലെന്നപോലെ). ഔട്ട്പുട്ടുമായി പ്രോഗ്രാം ഔട്ട്പുട്ടിനെ ആശയക്കുഴപ്പത്തിലാക്കുന്നത് ഒഴിവാക്കാനും ഇത് സഹായിക്കുന്നു സ്ട്രെയ്സ് കൺസോളിൽ.

കൂടുതൽ ആർഗ്യുമെന്റ് ഡാറ്റ കാണുന്നതിന് -s ഉപയോഗിക്കുക

മുകളിലെ ഉദാഹരണ ട്രെയ്‌സിൽ പിശക് സന്ദേശത്തിന്റെ രണ്ടാം പകുതി കാണിക്കാത്തത് നിങ്ങൾ ശ്രദ്ധിച്ചിരിക്കാം. കാരണം സ്ട്രെയ്സ് സ്ട്രിംഗ് ആർഗ്യുമെന്റിന്റെ ആദ്യ 32 ബൈറ്റുകൾ മാത്രമാണ് ഡിഫോൾട്ട് കാണിക്കുന്നത്. നിങ്ങൾക്ക് കൂടുതൽ കാണണമെങ്കിൽ, ഇതുപോലുള്ള എന്തെങ്കിലും ചേർക്കുക -s 128 കോളിലേക്ക് സ്ട്രെയ്സ്.

-y ഫയലുകൾ, സോക്കറ്റുകൾ മുതലായവ ട്രാക്ക് ചെയ്യുന്നത് എളുപ്പമാക്കുന്നു.

"എല്ലാം ഫയലാണ്" എന്നതിനർത്ഥം *നിക്സ് സിസ്റ്റങ്ങൾ എല്ലാ ഐ/ഒയും ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ ഉപയോഗിച്ച് ചെയ്യുന്നു, അത് ഒരു ഫയലിനോ നെറ്റ്‌വർക്കിനോ അല്ലെങ്കിൽ ഇന്റർപ്രോസസ് പൈപ്പുകൾക്കോ ​​ബാധകമാണ്. ഇത് പ്രോഗ്രാമിംഗിന് സൗകര്യപ്രദമാണ്, എന്നാൽ നിങ്ങൾ പൊതുവായി കാണുമ്പോൾ യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് ട്രാക്ക് ചെയ്യുന്നത് ബുദ്ധിമുട്ടാക്കുന്നു വായിക്കുക и എഴുതുക സിസ്റ്റം കോൾ ട്രെയ്സ് ഫലങ്ങളിൽ.

ഒരു ഓപ്പറേറ്ററെ ചേർക്കുന്നതിലൂടെ -у, നിങ്ങൾ നിർബന്ധിക്കും സ്ട്രെയ്സ് ഔട്ട്‌പുട്ടിലെ ഓരോ ഫയൽ ഡിസ്‌ക്രിപ്‌റ്ററും അത് ചൂണ്ടിക്കാണിക്കുന്നതിന്റെ ഒരു കുറിപ്പിനൊപ്പം വ്യാഖ്യാനിക്കുക.

-p** ഉപയോഗിച്ച് ഇതിനകം പ്രവർത്തിക്കുന്ന ഒരു പ്രോസസ്സിലേക്ക് അറ്റാച്ചുചെയ്യുക

ചുവടെയുള്ള ഉദാഹരണത്തിൽ നിന്ന് നിങ്ങൾ കാണുന്നത് പോലെ, ചിലപ്പോൾ നിങ്ങൾ ഇതിനകം പ്രവർത്തിക്കുന്ന ഒരു പ്രോഗ്രാം കണ്ടെത്തേണ്ടതുണ്ട്. ഇത് പ്രോസസ്സ് 1337 ആയി പ്രവർത്തിക്കുന്നുവെന്ന് അറിയാമെങ്കിൽ (ഔട്ട്പുട്ടിൽ നിന്ന് പറയുക ps), തുടർന്ന് നിങ്ങൾക്ക് ഇത് ഇതുപോലെ കണ്ടെത്താനാകും:

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

നിങ്ങൾക്ക് റൂട്ട് അവകാശങ്ങൾ ആവശ്യമായി വന്നേക്കാം.

കുട്ടികളുടെ പ്രക്രിയകൾ നിരീക്ഷിക്കാൻ -f ഉപയോഗിക്കുക

സ്ട്രെയ്സ് സ്ഥിരസ്ഥിതിയായി, ഇത് ഒരു പ്രോസസ്സ് മാത്രമേ കണ്ടെത്തൂ. ഈ പ്രക്രിയ ചൈൽഡ് പ്രോസസുകളെ സ്പോൺ ചെയ്യുകയാണെങ്കിൽ, ചൈൽഡ് പ്രോസസ് സ്പോൺ ചെയ്യാനുള്ള സിസ്റ്റം കോൾ കാണാൻ കഴിയും, എന്നാൽ ചൈൽഡ് പ്രോസസിന്റെ സിസ്റ്റം കോളുകൾ പ്രദർശിപ്പിക്കില്ല.

ഒരു ചൈൽഡ് പ്രോസസ്സിലാണ് പിശക് എന്ന് നിങ്ങൾ കരുതുന്നുവെങ്കിൽ, പ്രസ്താവന ഉപയോഗിക്കുക -f, ഇത് അതിന്റെ കണ്ടെത്തൽ പ്രാപ്തമാക്കും. ഔട്ട്പുട്ട് നിങ്ങളെ കൂടുതൽ ആശയക്കുഴപ്പത്തിലാക്കും എന്നതാണ് ഇതിന്റെ പോരായ്മ. എപ്പോൾ സ്ട്രെയ്സ് ഒരു പ്രോസസ്സ് അല്ലെങ്കിൽ ഒരു ത്രെഡ് ട്രെയ്‌സ് ചെയ്യുന്നു, ഇത് കോൾ ഇവന്റുകളുടെ ഒരൊറ്റ സ്ട്രീം കാണിക്കുന്നു. ഇത് ഒരേസമയം ഒന്നിലധികം പ്രക്രിയകൾ കണ്ടെത്തുമ്പോൾ, ഒരു സന്ദേശം വഴി തടസ്സപ്പെട്ട കോളിന്റെ ആരംഭം നിങ്ങൾ കണ്ടേക്കാം , പിന്നെ - മറ്റ് എക്സിക്യൂഷൻ ബ്രാഞ്ചുകൾക്കായുള്ള ഒരു കൂട്ടം കോളുകൾ, അതിനുശേഷം മാത്രമേ - ആദ്യത്തേതിന്റെ അവസാനം . അല്ലെങ്കിൽ ഓപ്പറേറ്റർ ഉപയോഗിച്ച് എല്ലാ ട്രെയ്സ് ഫലങ്ങളും വ്യത്യസ്ത ഫയലുകളായി വിഭജിക്കുക -ff (വിശദാംശങ്ങളിൽ നേതൃത്വം ആ സമയത്ത് സ്ട്രെയ്സ്).

-e ഉപയോഗിച്ച് ട്രെയ്സ് ഫിൽട്ടർ ചെയ്യുക

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, സാധ്യമായ എല്ലാ സിസ്റ്റം കോളുകളുടെയും ഒരു യഥാർത്ഥ കൂമ്പാരമാണ് ട്രേസിന്റെ ഫലം. പതാക -e നിങ്ങൾക്ക് ട്രെയ്സ് ഫിൽട്ടർ ചെയ്യാൻ കഴിയും (കാണുക നേതൃത്വം ആ സമയത്ത് സ്ട്രെയ്സ്). ഫിൽട്ടർ ചെയ്ത ട്രെയ്‌സ് പ്രവർത്തിപ്പിക്കുന്നത് ഫുൾ ട്രെയ്‌സ് ചെയ്യുന്നതിനേക്കാൾ വേഗതയുള്ളതാണ് എന്നതാണ് പ്രധാന നേട്ടം grep` at. സത്യം പറഞ്ഞാൽ, ഞാൻ മിക്കവാറും എപ്പോഴും ശ്രദ്ധിക്കുന്നില്ല.

എല്ലാ തെറ്റുകളും മോശമല്ല

ലളിതവും പൊതുവായതുമായ ഒരു ഉദാഹരണം, ഒരേസമയം നിരവധി സ്ഥലങ്ങളിൽ ഒരു ഫയലിനായി തിരയുന്ന ഒരു പ്രോഗ്രാമാണ്, ഒരു ഷെൽ എക്സിക്യൂട്ടബിൾ ഫയൽ അടങ്ങുന്ന ഒരു ഡയറക്ടറി തിരയുന്നത് പോലെ:

$ 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
...

"ഒരു പിശക് റിപ്പോർട്ടുചെയ്യുന്നതിന് മുമ്പ് അവസാനമായി പരാജയപ്പെട്ട അഭ്യർത്ഥന" പോലുള്ള ഹ്യൂറിസ്റ്റിക്സ് പ്രസക്തമായ പിശകുകൾ കണ്ടെത്തുന്നതിൽ നല്ലതാണ്. അതെന്തായാലും, അവസാനം മുതൽ ആരംഭിക്കുന്നത് യുക്തിസഹമാണ്.

സി പ്രോഗ്രാമിംഗ് ട്യൂട്ടോറിയലുകൾ സിസ്റ്റം കോളുകൾ മനസ്സിലാക്കാൻ നിങ്ങളെ സഹായിക്കും.

സി ലൈബ്രറികളിലേക്കുള്ള സ്റ്റാൻഡേർഡ് കോളുകൾ സിസ്റ്റം കോളുകളല്ല, മറിച്ച് നേർത്ത ഉപരിതല പാളി മാത്രമാണ്. അതിനാൽ, സിയിൽ എങ്ങനെ, എന്തുചെയ്യണമെന്ന് നിങ്ങൾ അൽപ്പമെങ്കിലും മനസ്സിലാക്കിയാൽ, സിസ്റ്റം കോൾ ട്രേസിന്റെ ഫലങ്ങൾ മനസ്സിലാക്കുന്നത് നിങ്ങൾക്ക് എളുപ്പമായിരിക്കും. ഉദാഹരണത്തിന്, നെറ്റ്‌വർക്ക് സിസ്റ്റങ്ങളിലേക്കുള്ള കോളുകൾ ഡീബഗ്ഗ് ചെയ്യുന്നതിൽ നിങ്ങൾക്ക് പ്രശ്‌നമുണ്ട്, അതേ ക്ലാസിക് നോക്കുക നെറ്റ്‌വർക്ക് പ്രോഗ്രാമിംഗിലേക്കുള്ള ബിജയുടെ ഗൈഡ്.

കൂടുതൽ സങ്കീർണ്ണമായ ഡീബഗ്ഗിംഗ് ഉദാഹരണം

ലളിതമായ ഡീബഗ്ഗിംഗിന്റെ ഉദാഹരണം ജോലി ചെയ്യുമ്പോൾ ഞാൻ കൂടുതലായി കൈകാര്യം ചെയ്യേണ്ടതിന്റെ ഒരു ഉദാഹരണമാണെന്ന് ഞാൻ ഇതിനകം പറഞ്ഞു സ്ട്രെയ്സ്. എന്നിരുന്നാലും, ചിലപ്പോൾ ഒരു യഥാർത്ഥ അന്വേഷണം ആവശ്യമാണ്, അതിനാൽ കൂടുതൽ വിപുലമായ ഡീബഗ്ഗിംഗിന്റെ യഥാർത്ഥ ജീവിത ഉദാഹരണം ഇതാ.

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) ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്ററാണെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും, ഇത് എല്ലാ I/O പ്രോസസ്സിംഗിനും *nix ഉപയോഗിക്കുന്നു. ഫയൽ ഡിസ്ക്രിപ്റ്റർ 3 പ്രതിനിധീകരിക്കുന്നത് എന്താണെന്ന് ഞാൻ എങ്ങനെ കണ്ടെത്തും? ഈ പ്രത്യേക സാഹചര്യത്തിൽ, നിങ്ങൾക്ക് പ്രവർത്തിപ്പിക്കാൻ കഴിയും സ്ട്രെയ്സ് ഓപ്പറേറ്ററുമായി -у (മുകളിൽ കാണുക) അത് സ്വയമേവ നിങ്ങളോട് പറയും, എന്നാൽ ഇതുപോലുള്ള കാര്യങ്ങൾ കണ്ടുപിടിക്കാൻ, ഫലങ്ങൾ എങ്ങനെ വായിക്കാമെന്നും പാഴ്‌സ് ചെയ്യാമെന്നും അറിയുന്നത് ഉപയോഗപ്രദമാണ്.

ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്ററിന്റെ ഉറവിടം നിരവധി സിസ്റ്റം കോളുകളിൽ ഒന്നായിരിക്കാം (ഇതെല്ലാം ഡിസ്ക്രിപ്റ്റർ എന്തിനുവേണ്ടിയാണെന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു - ഒരു കൺസോൾ, ഒരു നെറ്റ്‌വർക്ക് സോക്കറ്റ്, ഫയൽ തന്നെ അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും), എന്നാൽ അങ്ങനെയാകട്ടെ, ഞങ്ങൾ തിരയുന്നു 3 തിരികെ നൽകി കോളുകൾ (അതായത്, ട്രെയ്‌സിംഗ് ഫലങ്ങളിൽ ഞങ്ങൾ "= 3" തിരയുന്നു). ഈ ഫലത്തിൽ അവയിൽ 2 ഉണ്ട്: തുറക്കുക ഏറ്റവും മുകളിൽ ഒപ്പം സോക്കറ്റ് മധ്യത്തിൽ. തുറക്കുക ഫയൽ തുറക്കുന്നു പക്ഷേ അടയ്ക്കുക(3) അത് വീണ്ടും അടയുന്നതായി കാണിക്കും. (Rake: ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ തുറക്കുകയും അടയ്ക്കുകയും ചെയ്യുമ്പോൾ അവ വീണ്ടും ഉപയോഗിക്കാവുന്നതാണ്). വിളി സോക്കറ്റ് () ഇത് മുമ്പത്തെ അവസാനമായതിനാൽ അനുയോജ്യമാണ് വായിക്കുക (), കൂടാതെ bcrontab ഒരു സോക്കറ്റിലൂടെ എന്തെങ്കിലും ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നുവെന്ന് ഇത് മാറുന്നു. ഫയൽ ഡിസ്ക്രിപ്റ്റർ ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്ന് അടുത്ത വരി കാണിക്കുന്നു unix ഡൊമെയ്ൻ സോക്കറ്റ് വഴിയിൽ /var/run/bcron-spool.

അതിനാൽ, ബന്ധപ്പെട്ട പ്രക്രിയ ഞങ്ങൾ കണ്ടെത്തേണ്ടതുണ്ട് unix സോക്കറ്റ് മറുവശത്ത്. സെർവർ വിന്യാസങ്ങൾ ഡീബഗ്ഗ് ചെയ്യുന്നതിന് ഉപയോഗപ്രദമാണ് ഈ ആവശ്യത്തിനായി രണ്ട് വൃത്തിയുള്ള തന്ത്രങ്ങൾ. ആദ്യത്തേത് ഉപയോഗിക്കുക എന്നതാണ് netstat അല്ലെങ്കിൽ പുതിയത് 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 മുതലായവ) ഈ പ്രക്രിയ ഒരു ചൈൽഡ് പ്രോസസ് ഉണ്ടാക്കുന്നു, അത് നിങ്ങൾ ഊഹിക്കുന്നതുപോലെ, യഥാർത്ഥ ജോലി ചെയ്യുന്നു. നിങ്ങൾക്ക് അവളുടെ പാത പിടിക്കണമെങ്കിൽ, കോളിലേക്ക് ചേർക്കുക സ്‌ട്രേസ് -എഫ്. പുതിയ ഫലത്തിലെ പിശക് സന്ദേശത്തിനായി സ്‌ട്രെയ്‌സ് ഉപയോഗിച്ച് തിരയുമ്പോൾ നമ്മൾ കണ്ടെത്തുന്നത് ഇതാണ് -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/spool.21470.1573692319.854640 (നിലവിലെ പ്രവർത്തിക്കുന്ന ഡയറക്ടറിയുമായി ബന്ധപ്പെട്ടത്). നിലവിലെ വർക്കിംഗ് ഡയറക്‌ടറി ഞങ്ങൾക്ക് അറിയാമെങ്കിൽ, മുഴുവൻ പാതയും ഞങ്ങൾ അറിയുകയും പ്രോസസിന് അതിന്റെ താൽക്കാലിക ഫയൽ സൃഷ്ടിക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ടാണെന്ന് കണ്ടെത്താനും കഴിയും. നിർഭാഗ്യവശാൽ, പ്രോസസ്സ് ഇതിനകം പുറത്തുകടന്നതിനാൽ നിങ്ങൾക്ക് ഉപയോഗിക്കാൻ കഴിയില്ല lsof -p 21470 നിലവിലെ ഡയറക്‌ടറി കണ്ടെത്തുന്നതിന്, എന്നാൽ നിങ്ങൾക്ക് വിപരീത ദിശയിൽ പ്രവർത്തിക്കാൻ കഴിയും - ഡയറക്ടറി മാറ്റുന്ന PID 21470 സിസ്റ്റം കോളുകൾക്കായി നോക്കുക. (ഒന്നും ഇല്ലെങ്കിൽ, PID 21470 അവ അതിന്റെ രക്ഷിതാവിൽ നിന്ന് പാരമ്പര്യമായി ലഭിച്ചിരിക്കണം, ഇത് ഇതിനകം തന്നെ lsof -പി കണ്ടെത്താൻ കഴിയില്ല.) ഈ സിസ്റ്റം കോൾ ആണ് 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/spool/cron/tmp/spool.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/spool/cron/tmp/. ലളിതമായ കമാൻഡ് ചൗൺ ക്രോൺ /var/spool/cron/tmp/ ഫോഴ്സ് ചെയ്യും bcron ശരിയായി പ്രവർത്തിക്കുക. (അത് പ്രശ്‌നമല്ലെങ്കിൽ, അടുത്തതായി സംശയിക്കേണ്ടത് SELinux അല്ലെങ്കിൽ AppArmor പോലുള്ള ഒരു കേർണൽ സെക്യൂരിറ്റി മൊഡ്യൂളാണ്, അതിനാൽ ഞാൻ കെർണൽ സന്ദേശ ലോഗ് പരിശോധിക്കും dmesg.)

ആകെ

ഒരു തുടക്കക്കാരനെ സംബന്ധിച്ചിടത്തോളം സിസ്റ്റം കോൾ ട്രെയ്‌സുകൾ വളരെ വലുതായിരിക്കും, എന്നാൽ പൊതുവായ വിന്യാസ പ്രശ്‌നങ്ങളുടെ മുഴുവൻ ക്ലാസ് ഡീബഗ് ചെയ്യുന്നതിനുള്ള ഒരു ദ്രുത മാർഗമാണ് അവയെന്ന് ഞാൻ കാണിച്ചുതരുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. ഒരു മൾട്ടിപ്രോസസ് ഡീബഗ് ചെയ്യാൻ ശ്രമിക്കുന്നത് സങ്കൽപ്പിക്കുക bcronഒരു ഘട്ടം ഘട്ടമായുള്ള ഡീബഗ്ഗർ ഉപയോഗിക്കുന്നു.

സിസ്‌റ്റം കോൾ ശൃംഖലയ്‌ക്കൊപ്പം ട്രെയ്‌സ് ഫലങ്ങൾ പിന്നോട്ട് പാഴ്‌സ് ചെയ്യുന്നതിന് വൈദഗ്ദ്ധ്യം ആവശ്യമാണ്, എന്നാൽ ഞാൻ പറഞ്ഞതുപോലെ, മിക്കവാറും എല്ലായ്‌പ്പോഴും ഉപയോഗിക്കുന്നു സ്ട്രെയ്സ്, എനിക്ക് ട്രെയ്സ് ഫലം ലഭിക്കുകയും അവസാനം മുതൽ ആരംഭിക്കുന്ന പിശകുകൾക്കായി നോക്കുകയും ചെയ്യുന്നു. എന്തായാലും, സ്ട്രെയ്സ് ഡീബഗ്ഗിംഗിൽ ധാരാളം സമയം ലാഭിക്കാൻ എന്നെ സഹായിക്കുന്നു. നിങ്ങൾക്കും ഉപകാരപ്പെടുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

അവലംബം: www.habr.com