macOS intern

Teil 5: Wie die Konsole funktioniert – und was sie bringt

macOS führt über fast jede Aktion und jedes Problem in Form von Protokollmeldungen Buch. Die Ausgaben von Apples App Konsole und dem log-Befehl im Terminal können jedoch nicht nur Admins und Entwickler auswerten, sondern auch fortgeschrittene Anwender – wenn sie ein paar Dinge beachten.

Von Tobias Engler

Unter dem Begriff Logging versteht man allgemein das Aufzeichnen und Mitschreiben von Aktionen. Einzelne Anwendungen können so etwa belegen, dass bestimmte Schritte oder Transaktionen ausgeführt wurden – oder auch nicht. Das ist nicht nur bei Geschäftsanwendungen wie Datenbanken wichtig, um im Ernstfall nachvollziehen zu können, wer welche Änderungen gemacht hat. Es hilft auch Privatanwendern bei der Fehlersuche. Was trivial anmutet, ist auf Systemebene gar nicht so simpel: Bei mehreren hundert gleichzeitig laufenden Prozessen kommen innerhalb kurzer Zeit Tausende von Nachrichten zusammen, die in eine sinnvolle Struktur gebracht werden müssen. Hinzu kommt, dass diese Protokollaktivitäten das System nicht komplett ausbremsen sollen, jeder Vorgang benötigt schließlich Ressourcen in Form von Rechenzeit und eventuell auch Dateisystem- und Speicherzugriffen. Das übernimmt in älteren Sytemen ASL (siehe Kasten), macOS Sierra hat Apple ein komplett neues Logging-System spendiert.

Von macOS 10.4 („Tiger“) an bis macOS 10.11 hat Apple ausschließlich die Apple System Log Facility, ASL, verwendet. Diese besteht aus mehreren Komponenten: der ASL-API, einer minimalen Kernel-Logging-API (die Protokollmeldungen über die Befehle printf und IOLog entgegen nimmt), dem syslog-Kommandozeilen-Befehl und dem syslog-Daemon syslogd.

Letzterem kommt eine zentrale Rolle zu: Er wartet nämlich an unterschiedlichen Kommunikationsendpunkten, so genannten Sockets, auf Nachrichten der einzelnen Komponenten und überführt diese dann an den richtigen Ort. Dabei bestimmen Konfigurationsdateien wie /etc/asl.conf und /etc/syslog.conf, was mit welcher Nachricht geschehen soll, etwa, wo diese abzulegen ist.

Standardmäßig landen via ASL erzeugte Nachrichten in einem „Data Store“, normalerweise /var/log/asl. Das gilt zum Beispiel für vom Programmierer mit NSLog() erzeugte Meldungen. NSLog() – eine Funktion des Foundation-Framework – ist lediglich ein Wrapper für die ASL-API. In diesem Store abgelegte Daten liegen in einem von Apple nicht näher dokumentierten binären Datenformat vor, lassen sich aber zum Beispiel im Terminal mit dem Befehl cat /var/log/asl/<Datum als: JJJJ.MM.TT>.G80.asl | more flott einsehen. cat ist dabei für die Ausgabe zuständig, more wartet nach jeder Bildschirmseite auf einen Tastendruck. Vernünftig durchsuchen kann man die Daten so indes nicht. Programmierer können über die API natürlich effizienter suchen, etwa mit asl_search().

Bei den von syslog generierten Meldungen handelt es sich um reine Textdateien. Die Einträge sind unter /var/log/system.log zu finden. Dort wandern auch vom Programmierer über IOLog() verschickte Meldungen hin. Das Textformat ermöglicht praktischerweise Anfragen wie cat /var/log/system.log | grep syslogd auf der Kommandozeile. Wie syslog gehört syslogd zum BSD-Unterbau (Unix) des macOS. Im Terminal kann man übrigens auch leicht selbst Log-Einträge schreiben: Der Befehl logger „<Text>“ gibt den angegeben Text einfach an syslog weiter.

Das sogenannte „Unified Logging“ arbeitet sowohl unter macOS als auch unter iOS ab 10.0, tvOS ab 10.0 und watchOS ab 3.0. Mit os_log (aus dem os-Framework) gibt es nur noch eine offizielle API, die unter Objective-C, C++ und Swift zur Verfügung steht. Passend dazu ist unter Sierra mit logd ein neuer Daemon aufgetaucht – das Pendant zu syslogd. Die Architektur des Systems ist laut Apple so ausgelegt, dass das Logging mit minimaler Belastung des Systems zur Laufzeit erfolgen kann. Alle aufwendigen Vorgänge werden auf den Zeitpunkt der Ausgabe verlagert und beeinflussen die loggenden Prozesse nicht. Die alten (Programmier-)Schnittstellen ASL-API, syslog und NSLog existieren weiterhin.