Intressant att fixa de biblioteksfel och buggar du observerar när du installerar en cool ny program på Linux? Kolla in den här artikeln som visar hur du använder ltrace, beväpnar dig med verktyget som behövs för att felsöka bibliotekssamtal.
Vad är ett bibliotek ?
De flesta känner till .dll/.DLL-filer (Dynamic Link Libraries) i Windows. Linux-ekvivalenten är en .so-fil, ett delat objekt, ofta kallat bara bibliotek.
Ett bibliotek kan användas av en applikation som tillåter att programmet använder funktionalitet utanför dess programkod. Till exempel kanske en webbserver vill använda ett disk-I/O-bibliotek skrivet av operativsystemleverantören eller någon annan tredje part. Det är ett sätt att dela vanliga varor och intressen i de flesta, om inte alla, operativsystem.
Bibliotek kan laddas antingen dynamiskt vid körning (till exempel när det anropande programmet startar) eller kan kompileras till en målapplikation/binär. De kommer därför alltid att laddas (oavsett om de används eller inte), som en del av, och närhelst applikationen som har dem sammanställt/inbyggd startas.
Om du vill lära dig mer om bibliotek, deras beroenden och ldd-verktyget kanske du vill läsa om hur du arbetar med delade objektberoenden i Linux. Ldd-verktyget är ett annat praktiskt verktyg att ha i alla mer avancerade Linux-användarverktygslådor.
vad är ltrace ?
Det finns olika spårningsverktyg i Linux, som spårning för att spåra systemanrop och signaler och spåra rutan för att spåra nätverksdirigering. Ltrace-verktyget/verktyget spårar alla bibliotekssamtal.
Annons
Om du har läst vårt arbete med Shared Object (Library) -beroenden i Linux-artikeln (länkad ovan) har du redan sett hur du kan ta reda på vilka bibliotek en viss binär är länkad till med hjälp av ldd-verktyget. Syftet och funktionaliteten med ltrace är något annorlunda; mycket i linje med strace, ltrace-kommandot spårar alla bibliotekssamtal som ett visst program gör medan det körs.
Liksom att sträcka kan vi starta ett program under (tänk på det som en hierarki) spår. Vi anger helt enkelt det program som ltrace ska starta som det första alternativet att spåra, och ltrace startar det programmet för oss och börjar omedelbart (på en högre nivå) för att spåra alla samtal till valfritt (operativsystem eller installerad tredje part) bibliotek.
Det görs genom att fånga upp och spela in de dynamiska bibliotekssamtal som görs av programmet som körs. Det kommer också att spåra alla signaler som skickas till det program som körs, mycket lik strace (och om så önskas kan denna funktion inaktiveras genom att ange alternativet -b eller motsvarande – inga signaler att spåra).
Observera att termen dynamisk är av stor betydelse här; ltrace spårar samtal till externa bibliotek (i form av .so- eller .a-filer), dvs bibliotek som inte direkt sammanställs till ett program; dynamiska bibliotek. Således, om du har en binär med statiskt (sammanställda) bibliotek, kommer ltrace inte att kunna se/spåra sådana interna samtal.
Installera < i> ltrace
För att installera ltrace på din Debian/Apt-baserade Linux-distribution (som Ubuntu och Mint), kör du följande kommando i din terminal:
sudo apt install ltrace
Annons < br>
För att installera ltrace på din RedHat/Yum-baserade Linux-distribution (som RHEL, Centos och Fedora), kör följande kommando i din terminal:
sudo yum install ltrace
Använda ltrace
Låt oss skapa en liten testmiljö:
sudo apt installera tar xz-utils mkdir ~/arbetsyta & amp; & amp; cd ~/workspace touch a b c
Här installerade vi tar och xz genom att installera xz-utils (du kan använda sudo yum installera tar xz istället om du använder Centos/RHEL/Fedora). Därefter skapade vi en katalog ~/arbetsyta och hoppade in i den. Vi gjorde sedan tre tomma filer med hjälp av kommandot touch, nämligen filer a, b och c.
Låt oss börja med att komprimera våra tre filer till en ( tar kombinerad och xz komprimerat) archive.tar.xz-arkiv medan du kör samma under ltrace och observerar ltrace-utdata:
ltrace tar -hcf –xz archive.tar.xz *
Vi ser bara en liten mängd utdata. Vi kan se att vårt program avslutades framgångsrikt (arkivfilen skapades), dvs. status 0: en utgångskod på 0 betyder alltid framgång i Linux (även om programmet måste ha utgångskoder implementerade korrekt).
Detta är inte särskilt användbart hittills. Att resonera i några sekunder om hur tjära fungerar här kommer snabbt att avslöja vår nästa strategi. Den ivriga läsaren kan också ha förstått att tjärkommandot internt skulle kalla xz-kommandot. Alternativet –xz som skickas till vår tjärkommandorad säkerställer att xz-programmet används för komprimering.
Den sekundära processen (eller den tredje i den övergripande hierarkin) nämligen xz (hierarki: ltrace & gt; tar & gt; xz) startas med tjära när det behövs. Som sådan måste vi spåra barnprocesserna för programmet som körs under ltrace, dvs. tjära. Vi kan göra detta genom att ange följande (-f) -alternativ för att spåra:
ltrace -f tjära -hcf –xz archive.tar.xz * Annons
Observera att det är viktigt att ange -f-alternativet direkt bakom ltrace och inte senare i kommandoraden efter exempelvis tar. Anledningen är att vi vill ange det här alternativet att spåra och inte till tar-kommandot. Alla alternativ efter tjärkommandot är tjärspecifika alternativ medan -f är ett alternativ som är specifikt att spåra.
Utdata är lite mer intressant. Vi observerar inga bibliotekssamtal (av någon form) än, men vi ser åtminstone att två delprocesser är gafflade (not exec ()) och att båda delprocesserna avslutas med status 0. Praktiskt och allt bra.
Så var är våra bibliotekssamtal? När vi kontrollerar tar och xz (de två programmen som kommer att användas av kommandot för att skapa arkivfilen) med ldd, inser vi snabbt att de flesta bibliotek som båda programmen använder är systembibliotek:
var är tar var xz ldd/bin/tar ldd/usr/bin/xz
Vi måste alltså gå ett steg längre och möjliggöra spårning av systembibliotekssamtal genom att ange alternativet -S för att spåra. Det här alternativet är inaktiverat/inaktiverat som standard eftersom utdata skulle bli lite detaljerade, och det antas att systembibliotek i allmänhet är mycket mer stabila och därför inte behöver spåras till att börja med. Låt oss titta.
ltrace -fS tar -hcf –xz archive.tar.xz *
Eller för teständamål:
ltrace -fS tar -hcf –xz archive.tar.xz * 2 & gt; & amp; 1 | head -n10 ltrace -fS tar -hcf –xz archive.tar.xz * 2 & gt; & amp; 1 | svans -n10
Eftersom produktionen var betydande var vi tvungna att fånga de första och sista tio raderna med hjälp av ett huvud- och svanskommando. För att kunna använda dessa kommandon var vi tvungna att omdirigera stderr till stdout med 2 & gt; & amp; 1 omdirigering som ltrace kommer som standard att rapportera om stderr. Om du är intresserad av att lära dig mer om omdirigering, se Bash Automation and Scripting Basics (Part 3).
Annons
Nu när vi lade till alternativet -S kan vi se alla bibliotek som nås. Till exempel ser vi /etc/ld.so.preload nås. Utgången är sekventiell (uppifrån och ner), så om det finns andra händelser (underbehandling bearbetas osv.) Däremellan, visas dessa inline i det ögonblick de äger rum. Vi kan också lägga till alternativet -t för tidsbaserad utdata:
Avsluta
I den här artikeln introducerade och diskuterade vi det mångsidiga ltrace-programmet, vilket är ett utmärkt verktyg som gör att man kan spåra alla dynamiska bibliotek ett givet program gör. Vi installerade ltrace, skapade en testmiljö och körde några ltrace-kommandon med de mest använda alternativen.