Im Laufe der Jahre habe ich ausführlich darüber geschrieben, wie man softwarebezogene Probleme in der IT-Welt im Allgemeinen und in Linux im Besonderen beheben kann. Schließlich ist das schon seit langem mein Brot &Butter, und die Kunst des Problemlösens liegt mir immer noch sehr am Herzen. Eines der Themen, die ich ausführlich behandelt habe, ist gdb, der Inbegriff des Software-Debuggers. Das einzige Problem ist - Sie müssen innit um zu gewinnen.
Was ich damit meine - gdb ist ausgezeichnet, wenn Sie Ihre Probleme reproduzieren können. Aber wenn Sie Software in einer Produktionsumgebung ausführen, haben Sie möglicherweise nicht den Luxus, immer wieder Probleme auszulösen. Die Möglichkeit, Fehler zu erfassen und dann wiederzugeben, ist ein großer Vorteil, und sie kommt in Form von RR, einem Tool, das entwickelt wurde, um aufgezeichnete Ausführung von Software auf präzise, deterministische Weise zu debuggen. Mal sehen, was sich ergibt.
Auf die Plätze, fertig, fertig
Im Wesentlichen ist RR gdb und gdb ist RR. Die Idee ist einfach und die Umsetzung elegant. Sie führen Ihr Tool mit rr aus, erfassen die Ausführung (und den Fehler) und spielen die Aufzeichnung dann so oft ab, wie Sie möchten, außerhalb der Produktionsumgebung. Darüber hinaus können Sie bei schwer fassbaren Problemen möglicherweise ein wiederholbares Szenario erfassen, mit dem Sie die Grundursache schneller ermitteln und das Problem beheben können.
Ich habe RR in Fedora 32 installiert und konfiguriert. Ziemlich unkompliziert. Nun, die Ausführung erfordert etwas Liebe zum Detail. Wenn Sie das Programm als normaler Benutzer ausführen, wird möglicherweise eine Warnung angezeigt, dass RR privilegierte Kernel-Ereignisse nicht erfassen kann. Sie können dies ändern, und dann brauchen Sie sudo nicht. Ähnlich dem, was wir wirklich mit perf gesehen haben. Süß.
rr record ./seg
rr benötigt /proc/sys/kernel/perf_event_paranoid <=1, aber es ist 2.
Ändern Sie es auf 1 oder verwenden Sie 'rr record -n' (langsam).
Erwägen Sie, 'kernel.perf_event_paranoid =1' in /etc/sysctl.conf einzufügen
Es gibt viele Möglichkeiten, wie Sie dies ändern können. Setzen Sie einen Wert in /proc, verwenden Sie sysctl -w, um den Wert zu schreiben, bearbeiten Sie die Datei /etc/sysctl.conf manuell und laden Sie dann die Konfiguration neu. Welche Methode Sie auch wählen, Sie haben eine bessere Leistung und die Möglichkeit, alle erforderlichen Ereignisse zu verfolgen.
sudo sysctl -w kernel.perf_event_paranoid=1
Segfault-Beispiel
Um zu sehen, wie praktisch und nützlich RR ist, habe ich mich entschieden, dasselbe segfault-Beispiel aus dem gdb-Tutorial zu verwenden. Im Grunde eine Schleife mit malloc(), die zu einem Segmentierungsfehler führt:
#include
#include
main()
{
int *pointer;
int ich;
pointer =malloc(sizeof(int));
for (i =0; 1; i++)
{
pointer[i]=i;
printf("Zeiger[%d] =%d\n", i, Zeiger[i]);
}
return(0);
}
gcc -g seg.c -o seg
seg.c:4:1:Warnung:Rückgabetyp ist standardmäßig „int“ [-Wimplicit-int]
4 | main()
| ^~~~
RR-Aufnahme &RR-Wiedergabe
Die beiden Hauptfunktionen, die RR verwendet - Aufnahme und Wiedergabe.
rr record ./seg
...
Zeiger[33621] =33621
Zeiger[33622] =33622
Zeiger[33623] =33623
Segmentierungsfehler (core gelöscht)
Bitte beachten Sie, dass die tatsächliche Ausführung langsamer als gewöhnlich sein wird. Das bedeutet, dass RR bei zeitabhängigen Problemen möglicherweise nicht hilfreich ist. Ganz ähnlich wie wir es bei strace gesehen haben. Sie möchten deterministische Probleme, die zuverlässig repliziert werden können (das heißt unter den richtigen Bedingungen).
Wie auch immer, sobald wir das Problem aufgezeichnet haben, können wir es wiedergeben:
rr wiedergeben
Als RR das erste Mal geladen wurde, warnte es mich, dass Debug-Symbole nicht verfügbar waren – das ist ziemlich wichtig, wenn Sie wirklich in der Lage sein wollen, das Problem zu beheben. Es ist in keiner Weise RR-spezifisch, aber das sollte berücksichtigt werden - Sie können die fehlenden Pakete installieren, wenn Sie möchten, das Programm listet sogar den genauen Befehl auf, den Sie dafür verwenden können.
Remote-Debugging mit 127.0.0.1:7747
Lesen von Symbolen aus /lib64/ld-linux-x86-64.so.2...
(Keine Debugging-Symbole in /lib64/ld-linux-x86 gefunden -64.so.2)
0x00007f25ce73e110 in _start () von /lib64/ld-linux-x86-64.so.2
Fehlende separate Debuginfos, verwenden Sie:dnf debuginfo-install glibc-2.31-2 .fc32.x86_64--Tippen Sie
Sobald die RR-Schnittstelle geladen ist, befinden Sie sich im gdb-Land. Die Befehle sind die gleichen. Sie können Unterbrechungspunkte festlegen und dann Bedingungen verwenden, wann diese Unterbrechungspunkte tatsächlich aktiviert und die Ausführung der Aufgabe gestoppt werden sollen.
Pause 10
Bedingung 1 i ==33610
Fortfahren
Und die Debug-Session sieht in etwa so aus:
(rr) nächster
Zeiger[33611] =33611
9 für (i =0; 1; i++)
(rr) nächster
11 Zeiger[i]=i;
(rr) next
Programm empfangenes Signal SIGSEGV, Segmentierungsfehler.
0x000000000040116a in main() bei seg.c:11
11 pointer[i]=i;
Jetzt können Sie tiefer gehen und zusätzliche Überprüfungen durchführen. Der Hauptunterschied besteht darin, dass all dies auf einer aufgezeichneten Instanz Ihrer Software erfolgt, sodass Sie möglicherweise nicht in die tatsächliche Nutzung Ihrer Dienste und Anwendungen eingreifen. Idealerweise benötigen Sie ein cleveres Setup, das Probleme automatisch erkennt und aufzeichnet, aber das ist eine ganz andere Geschichte.
Schlussfolgerung
Ich habe nicht allzu viel Zeit mit RR verbracht, aber was ich sehe, gefällt mir. Das Programm verwendet die vertrauten, robusten Grundlagen von gdb, was bedeutet, dass Sie die Linux-Fehlerbehebung nicht von Grund auf neu lernen müssen. Darüber hinaus fügt es eine Ebene leistungsstarker Flexibilität hinzu, die es Ihnen ermöglicht, den Zeitdruck zu minimieren, der oft mit IT-Problemen verbunden ist – wie z. B. dem Absturz von Software. Sie können nach Belieben aufnehmen und wiedergeben. Dies bedeutet auch, dass Sie das Problem mit größerer Wahrscheinlichkeit finden, insbesondere wenn Sie mit komplizierten, langen Aufgabenausführungen zu tun haben.
Hoffentlich finden Sie dieses kurze Tutorial nützlich. In einer Welt, in der es für jede Mahlzeit zehn Köche und fünfzig redundante Linux-Tools für jeden Bedarf gibt, ist es schön, Software zu sehen, die sinnvolle zusätzliche Funktionen bietet, anstatt eine Neuauflage des Gleichen. Nun, Sie haben jetzt ein weiteres Dienstprogramm in Ihrem Arsenal, was auch eine Entschuldigung weniger dafür bedeutet, dass Sie diese lästigen Softwareprobleme nicht schnell genug lösen können. So funktioniert es, nein.