Häälestame tarkvara suurendamise koos strace'iga

Minu põhitöö on peamiselt tarkvarasüsteemide juurutamine, seega kulutan palju aega sellistele küsimustele vastamisele:

• Arendajal see tarkvara töötab, aga mul ei toimi. Miks?
• Eile töötas see tarkvara mul, aga täna ei tööta. Miks?

See on teatud tüüpi silumine, mis erineb tavalisest tarkvarasilumisest. Tavaline silumine keskendub koodi loogikale, samas kui juurutamise silumine käsitleb koodi ja keskkonna interaktsiooni. Isegi kui probleemi juureks on loogiline viga, tähendab fakt, et ühes masinas kõik töötab, aga teises mitte, et probleem on mingil moel keskkonnas.

Seetõttu on mul tavapäraste silumisvahendite asemel gdb teine tööriistakomplekt juurutamise silumiseks. Ja minu lemmikvahend küsimuse "Miks see tarkvara mul ei tööta?" lahendamiseks on strace.

Mis on strace?

strace — see on süsteemikutsungite jälgimise tööriist. Algul loodi see Linuxile, kuid samu silumise nippe saab teha ka teiste süsteemide tööriistadega (DTrace või ktrace).

Peamine kasutus on väga lihtne. Tuleb lihtsalt käivitada strace koos mõne käsuga ja see saadab dump'i kõikidest süsteemikutsungitest (kuid esmalt tuleb tõenäoliselt ise strace paigaldada) strace):

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

Mis on need süsteemikutsungid? Need on midagi nagu operatsioonisüsteemi tuuma API. Amatöörina oli tarkvaral otsene juurdepääs "riistvarale", millel see töötas. Kui näiteks oli vaja midagi ekraanile kuvada, siis mängiti sadamatega või videoseadmete mälu registeritega. Kui mitmeülesanne arvutisüsteemid said populaarseks, siis tekkis kaos, kuna erinevad rakendused võitlesid "riistvara" nimel. Ühe rakenduse vead võisid rivistada kõik teised rakendused või isegi kogu süsteemi. Siis said CPU-s privileegirežiimid (või "ringkaitse"). Kõige privileege saanud oli tuum: see sai täisjuurdepääsu "riistvarale", luues vähem privileege saanud rakendusi, kes pidid tuumalt juurdepääsu küsima, et suhelda "riistvaraga" — läbi süsteemikutsungite.

Binaarsetasemel erineb süsteemikõne veidi lihtsast funktsioonikõnest, kuid enamik programme kasutab standardbiblioteegi ümbrikku. St. POSIX C standardbiblioteegis on süsteemikõne funktsioon. write(), mis sisaldab kogu arhitektuurist sõltuvat koodi süsteemikõne jaoks. kirjutama.

Lühidalt öeldes toimub rakenduse igasugune suhtlemine oma keskkonnaga (arvutisüsteemidega) süsteemikõnede kaudu. Seega, kui tarkvara töötab ühel masinal ja mitte teisel, oleks hea vaadata süsteemikõnede jälgimise tulemusi. Kui täpsemalt, siis siin on teile loetelu tüüpilistest punktidest, mida saab analüüsida süsteemikõne jälgimise abil:

• Konsoli sisend-väljund
• Võrgu sisend-väljund
• Failisüsteemi juurdepääs ja failide sisend-väljund
• Protsessi-eluea haldamine
• Madala taseme mälu haldamine
• Juhtimisseadmete juurdepääs

Millal kasutada strace'i?

Teoorias strace kasutatakse kõigi kasutajaruumis olevate programmide puhul, kuna iga kasutajaruumis olev programm peab tegema süsteemikõnesid. See töötab efektiivsemalt kompileeritud madala taseme programmidega, kuid töötab ka kõrgema taseme keeltes nagu Python, kui õnnestub läbi murda täiendava müra kaudu exécutori ja tõlkija.

Kogu oma hiilguses strace näitab see ennast tarkvara silumiseks, mis töötab ühe masinaga hästi, kuid teisel lõpetab töö ootamatult, andes ebamugavaid teadet faile, õigusi või ebaõnnestunud katsete kohta teatud käskude täitmiseks jms... Kahju, aga see ei sobi nii hästi kõrgema taseme probleemidega, nagu sertifikaadi kontrollimise vead. Tavaliselt vajab see kombinatsiooni strace, mõnikord ltrace ja kõrgema taseme tööriistu (nagu käsurea tööriist openssl sertifikaadi silumiseks).

Näiteks võtame töö isoleeritud serveris, kuid süsteemikõnede jälgimist saab sageli teha ka keerukamatel juurutamisplatvormidel. Lihtsalt peab valima sobiva tööriistad.

Lihtsa silumise näidis

Oletame, et soovite käivitada fantastilise serverirakenduse foo, aga juhtub selline asi:

$ foo
Konfiguratsioonifaili avamine ebaõnnestus: Sellist faili või kausta ei leitud

Ilmselt ei õnnestunud tal leida teie kirjutatud konfigureerimisfaili. See juhtub, sest mõnikord, kui pakihaldurid rakendust kompileerivad, ületavad nad oodatud failide asukoha. Ja kui järgida paigaldusjuhendit ühele distributsioonile, leiad teises failid täiesti oodatust erinevates kohtades. Probleemi saaks lahendada paari sekundiga, kui veateade ütleks, kust konfigureerimisfaili otsida, aga see ei ütle. Kust siis otsida?

Kui lähtekoodile on juurdepääs, saab seda lugeda ja kõik välja selgitada. Hea varuplaan, aga mitte kõige kiirem lahendus. Võib kasutada samm-sammult tõrkeotsijat nagu gdb ja vaadata, mida programm teeb, aga palju tõhusam on kasutada tööriista, mis on spetsiaalselt loodud keskkonna interaktsiooni näitamiseks: strace.

Kokkuvõte strace võib tunduda ülearune, kuid hea uudis on see, et suure osa sellest võib julgelt tähelepanuta jätta. Tihti on kasulik kasutada operaatorit -o, et salvestada jälgimistulemused eraldi faili:

$ strace -o /tmp/trace foo
Viga konfiguratsioonifaili avamisel: Ei ole sellist faili või kausta
$ cat /tmp/trace
execve("foo", ["foo"], 0x7ffce98dc010 /* 16 vars */) = 0
brk(NULL)                               = 0x56363b3fb000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (Ei ole sellist faili või kausta)
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 (Ei ole sellist faili või kausta)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x2 (lipud O_RDWR)
brk(NULL)                               = 0x56363b3fb000
brk(0x56363b41c000)                     = 0x56363b41c000
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
write(3, "Viga konfiguratsioonifaili avamisel"..., 60) = 60
close(3)                                = 0
exit_group(1)                           = ?
+++ lõpetanud 1 +++

Umbes kogu esimese lehe väljund. strace — see on tavaliselt madala taseme ettevalmistus käivitamiseks. (Palju kõnesid mmap, mprotect, brk asjade jaoks, näiteks madala taseme mälu avastamine ja dünaamiliste raamatukogude peegeldamine.) Üldiselt, silumise ajal on väljundid strace parem lugeda kõige lõpust. Allosas on kõne kirjutama, mis väljendab veateadet. Vaatame üles ja näeme esimest ebaõnnestunud süsteemi kõnet — kõne openat, mis annab vea ENOENT („fail või kaust ei leitud“), proovides avada /etc/foo/config.json. Siin peaks olema konfiguratsioonifail.

See oli lihtsalt näide, kuid ma ütleksin, et 90% ajast, kui ma kasutan strace, ei ole keerulisemalt midagi muud teha. Allpool on täielik samm-sammuline juhend silumiseks:

• Ärge muretsege mitte selge veateate pärast programmi
• Käivitage programm uuesti koos strace
• Leidke jälgimise tulemustes veateade
• Liigake üles, kuni jõuate esimese ebaõnnestunud süsteemi kõnni

On väga tõenäoline, et 4. sammu süsteemi kõne näitab, kus asi valesti läks.

Näpunäited

Enne kui näitan keerulisema tõrkeotsingu näidet, jagan teiega mõningaid näpunäiteid tõhusaks kasutamiseks. strace:

man — teie sõber

Paljudel *nix süsteemidel saab täisnimekirja süsteemi kõnede kohta ydra, käivitades man syscalls. Näete selliseid asju nagu brk(2), mis tähendab, et rohkem teavet saab teada, käivitades man 2 brk.

Mõned väikesed käigud: man 2 fork näitab mulle lehte shelli kohta fork() ja GNU libc, mis, nagu selgub, on rakendatud kõne abil clone(). Kõne semantika fork jääb samaks, kui kirjutada programm, mis kasutab fork(), ja käivitada jälgimine — ma ei leia kõnesid fork, nende asemel on clone(). Sellised käigud ajavad segadusse, kui hakata võrreldama lähtekoodi väljundiga. strace.

Kasutage -o, et salvestada väljund faili

strace võib genereerida ulatusliku väljundi, seega on tihti kasulik salvestada jälgimise tulemused eraldi failidesse (nagu ülaltoodud näites). See aitab ka mitte segada programmi väljundit konsooli väljundiga. strace Kasutage -s, et vaadata rohkem argumendi andmeid

Olete kindlasti märganud, et veateate teises pooles ei ole ülaltoodud jälgimise näites näidatud. See on seetõttu, et

vaikimisi näitab vaid esimesed 32 baiti argumentide stringist. Kui soovite näha rohkem, lisage midagi nagu strace -s 128 kõne juurde -u hõlbustab failide ja socketite jälgimist jne. strace.

"Kõik on fail" tähendab, et *nix süsteemid teevad kõik sisendi ja väljundi koos failide descriptoritega, olgu need siis failide, võrguga või protsessidevahelised kanalid. See on mugav programmeerimisel, kuid takistab nägemast, mis tegelikult toimub, kui näete ühtekuuluvust

süsteemi kõnede jälgimise tulemustes. lugema ja kirjutama Lisades operaatori

-u , sunniteannotatsioonid olema iga faili deskriptoriga väljundis märkustega, millele see viitab. strace Kinnitage juba käimasolevale protsessile -p**

Nagu allolev näide näitab, on mõnikord vajalik jälgida programmi, mis on juba käimas. Kui teatakse, et see on käivitatud protsessina 1337 (ütleme, ülesannete põhjal)

siis on võimalik selle jälgimine nii: ps$ strace -p 1337 ...süsteemikõnede jälgimise väljund...

Võib-olla on teil vaja superkasutaja õigusi.

Kasutage -f, et jälgida alamprotsesse.

.

strace vaikimisi jälgib ainult ühte protsessi. Kui see protsess genereerib alaprotsesse, on võimalik näha süsteemset kõnet alaprotsessi loomisel, kuid alaprotsesside süsteemseid kõnesid ei kuvata.

Kui arvate, et viga on alaprotsessis, kasutage operaatorit -f, see aktiveerib selle jälgimise. Miinus on see, et väljund segab teid veel rohkem. Kui strace jälgib ühte protsessi või ühte haru, näitab see ühtset sündmuste voogu kõnedest. Kui see jälgib korraga mitut protsessi, võite näha kõne algust, mis katkestatakse sõnumiga <unfinished …>, seejärel rida kõnesid teiste täitmisharude jaoks ja alles siis esimese lõpetamine <… foocall resumed>. Või jagage kõik jälgimise tulemused erinevatesse failidesse, kasutades ka operaatorit -ff (üksikasjad — juhendist 6TB strace).

Filtreerige jälgimist -e abil

Nagu näete, on jälgimise tulemus tõeline hunnik kõigist võimalikest süsteemsetest kõnedest. Lippu -e saab jälgimist filtreerida (vt. juhend 6TB strace). Peamine eelis on see, et jälgimist käivitatakse filtreerimisega kiiremini kui täislise jälgimine ja seejärel grep`-ida. Kui aus olla, siis mulle peaaegu alati ei meeldi.

Kõik vead pole halvad

Lihtne ja levinud näide on programm, mis otsib faili kohe mitmes kohas, näiteks shell, mis otsib, kus korv- kataloog sisaldab täidetavat faili:

$ strace sh -c uname
...
stat("/home/user/bin/uname", 0x7ffceb817820) = -1 ENOENT (Sellist faili või katalooge ei ole)
stat("/usr/local/bin/uname", 0x7ffceb817820) = -1 ENOENT (Sellist faili või katalooge ei ole)
stat("/usr/bin/uname", {st_mode=S_IFREG|0755, st_size=39584, ...}) = 0
...

Häid ja halbu näiteid nagu „viimane ebaõnnestunud päring veateate eel“ on koos asjakohaste vigade leidmiseks. Üldiselt on mõistlik alustada kõige lõpust.

Süsteemsete kõnede mõistmiseks aitavad hästi C programmi juhendid

C-teekide standardkõned ei ole süsteemsed kõned, vaid ainult peen kiht. Seega, kui mõistate midagi, kuidas ja mida C-s teha, on teil lihtsam jälgimise tulemusi mõista. Näiteks, kui teil on probleeme võrgusüsteemide kõnede silumisel, vaadake klassikalist „Võrguprogrammeerimise juhend“ Bidgi.

Tõhusam silumise näide

Olen juba maininud, et lihtne tõrkeotsing on näide sellest, millega ma suuremal osal oma tööst tegelema pean. straceKuid mõnikord on vajalik tõeline uurimine, nii et siin on teile reaalsem ja keerulisem tõrkeotsingu näide.

bcron on ülesannete täitmise ajastaja, veel üks *nix deemonite teostus. cronSee on serveris paigaldatud, kuid kui keegi üritab taskuplaane redigeerida, juhtub järgmist:

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

Olgu, see tähendab, et bcron ta üritas kirjutada mingit faili, kuid tal ei õnnestunud, ja ta ei tunnista, miks. Teeme lahti strace:

# 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 +++

Umbes lõpus on tõrketeade, kirjutamakuid seekord on midagi muud. Esiteks ei ole asjakohast süsteemikõne viga, mis tavaliselt enne seda esineb. Teiseks, on näha, et keegi on juba tõrketeate lugenud. Tundub, et tõeline probleem on kuskil mujal ja bcrontab lihtsalt kordab teate.

Kui vaadata man 2 read, siis saab näha, et esimene argument (3) on failihaldur, mida *nix kasutab kõigi sisendi ja väljundi töötlemiseks. Kuidas teada saada, mis failihaldur 3 on? Antud konkreetses olukorras saab käivitada strace koos operaatoriga , sunnite (vt ülal), ja see räägib automaatselt, kuid selliste asjade arvutamiseks on kasulik teada, kuidas lugeda ja analüüsida jälgimistulemusi.

Failihalduri allikaks võib olla üks paljudest süsteemikõnedest (olenevalt sellest, milleks see haldur on — kas konsooli, võrgu soketi, failina või millegi muuna jaoks), kuid igal juhul otsime me kõnesid, tagastades 3 (st otsime "= 3" jälgimistulemustes). Selles tulemustes on neid 2: openat üleval ja socket keskel. openat Ava fail, kuid sulgeda(3) pärast seda näitab, et see suletakse taas. (Karma: failihaldureid saab taaskasutada, kui neid avatakse ja suletakse). Kõne socket() sobib, kuna see on viimane enne read(), ning selgub, et bcrontab töötab millegagi soketi kaudu. Järgmine rida näitab, et failihaldur on seotud unix domain socketiga tee kaudu /var/run/bcron-spool.

Seega tuleb leida protsess, mis on seotud unix socketiga teiselt poolt. Selleks on olemas paar peent trikki, ja mõlemad osutuvad kasulikeks serveri paigutuste tõrkeotsingul. Esimene — kasutada netstat või uuemat ss (socket status). Mõlemad käsud näitavad süsteemi aktiivseid võrguühendusi ja võtavad operaatori õpivad kuulavate socketite kirjeldamiseks, samuti operaatori -p kliendina socketiga ühendatud programmide kuvamiseks. (Kasuval võimalusi on palju rohkem, kuid selle ülesande jaoks on piisavad ka need kaks.)

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

See tähendab, et kuulav on käsk inixserver, mis tegeleb protsessi ID-ga 20629. (Ja juhuslikult kasutab ta socketina failikirjeldajat 3.)

Teine tõeliselt kasulik tööriist sama teabe leidmiseks on lsof. See loetleb kõik avatud failid (või failikirjeldajad) süsteemis. Samuti on võimalik saada teavet ühe konkreetse faili kohta:

# 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

Protsess 20629 on pikaajaline server, nii et sellele saab liita strace midagi sellist nagu strace -o /tmp/trace -p 20629. Kui redigeerida cron ülesannet teises terminalis – saame jälgimistulemused koos ilmneva veaga. Ja siin on tulemus:

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 (Taaskäivitamiseks, kui SA_RESTART on seadistatud)
--- 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 (Lasteprotsesse pole)
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 (Taaskäivitamiseks, kui SA_RESTART on seadistatud)
--- 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 (Lasteprotsesse pole)
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

(Viimane accept() ei lõpetata jälgimisel.) Ja kahjuks, see tulemus ei sisalda viga, mida me otsime. Me ei näe ühtegi teadet, mida bcrontag oleks socketile saatnud või sellelt vastu võtnud. Nende asemel on pidev protsessi juhtimine (clone, wait4, SIGCHLD ja see on tõsi.) See protsess tekitab alamprotsessi, mis, nagu võib arvata, teostab tegelikku tööd. Ja kui on vaja selle jälge leida, lisage väljakutsele strace -f. Siit me leiame, kui otsime veateate uutest tulemustest strace'i kaudu -f -o /tmp/trace -p 20629:

21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Ligipääs keelatud) 
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 (Sellist faili või katalooge ei ole)
21470 exit_group(111)                   = ?
21470 +++ lahkunud 111 +++

Näete, see on juba midagi. Protsess 21470 saab tõrke "ligipääs keelatud" proovides luua faili aadressil tmp/spool.21470.1573692319.854640 (seoses praeguse töökaustaga). Kui me lihtsalt teaksime praegust töökausta, teaksime ka täielikku teed ja saaksime välja selgitada, miks protsess ei saa seal oma ajutist faili luua. Kahjuks on protsess juba lõpetatud, seega ei saa me lihtsalt kasutada lsof -p 21470 praeguse kausta leidmiseks, kuid saame töötada tagasi — otsida süsteemi kutsungite PID 21470, mis muudavad kausta. (Kui neid pole, peab PID 21470 olema need vanemalt pärinud ja see on juba läbi lsof -p ei ole võimalik selgitada.) See süsteemikutsung on chdir (mida on lihtne teada saada, kasutades kaasaegseid otsingumootoreid). Ja siin on tulemused tagasipöördetest vastavalt jälgimise tulemustele, kuni serveri PID 20629-ni:

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 (Ligipääs keelatud) 
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 (Sellist faili või katalooge ei ole)
21470 exit_group(111)                   = ?
21470 +++ lahkunud 111 +++

(Kui te kaotate suuna, siis võib-olla peaksite lugema minu eelmist postitust nix protsesside ja kestade haldamisest.) Nii et server PID 20629 ei saanud luba faili luua aadressil /var/spool/cron/tmp/spool.21470.1573692319.854640. Tõenäoliselt on selle põhjuseks klassikalised failisüsteemi õiguste seadistused. Kontrollime:

# 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

Siin on probleem! Server töötab kasutaja cron'i alt, kuid ainult root'il on õigus kirjutada katalooge /var/spool/cron/tmp/. Lihtne käsk chown cron /var/spool/cron/tmp/ aitab bcron töötama õigesti. (Kui probleem ei olnud selles, siis järgmine kõige tõenäolisem kahtlusalune on tuumaseadmestiku turvamoodul, näiteks SELinux või AppArmor, seega peaksin kontrollima kerneliteate logi kasutades dmesg.)

Kokkuvõttes

Algajale võib süsteemikutsungite jälgimise tulemustes ära uppuda, kuid loodan, et olen näidanud, et need on kiire viis, et tõrkeotsinguks laia valikut levinud juurutusprobleeme. Kujutage ette, et üritate tõrkeotsingut multitegijate vahel bcron, kasutades samm-sammult tõrkeotsijat.

Jälgimiste tulemuste tagasipööramine süsteemikutsungite ahelas nõuab oskust, kuid nagu juba ütlesin, peaaegu alati, kasutades strace, lihtsalt saan jälgimistulemuse ja otsin vigu, alustades lõpust. Igatahes, strace aitab mul tõrkeotsingul tohutult aega säästa. Loodan, et see on kasulik ka teile.

Allikas: habr.com