{"id":2586,"date":"2025-06-18T08:00:00","date_gmt":"2025-06-18T06:00:00","guid":{"rendered":"https:\/\/www.fuhselab.de\/?p=2586"},"modified":"2025-04-04T11:17:44","modified_gmt":"2025-04-04T09:17:44","slug":"systemprotokollierung-3","status":"publish","type":"post","link":"https:\/\/www.fuhselab.de\/index.php\/2025\/06\/18\/systemprotokollierung-3\/","title":{"rendered":"Systemprotokollierung 3"},"content":{"rendered":"\n<p><br>F\u00fcr diesen Artikel interessiert uns die Systemprotokollierung des Bootvorganges und von Updates und Upgrades\u2026<\/p>\n\n\n\n<!--more-->\n\n\n\n<p><strong>Systemprotokollierung des Bootvorganges:<\/strong><\/p>\n\n\n\n<p>Im Dateisystem findet sich unter var\/log die Datei \u201eboot.log\u201c\u2026Sollte sich diese nur mit root-Rechten \u00f6ffnen lassen, geht die Reise direkt ins Terminal\u2026<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>sudo mousepad \/var\/log\/boot.log<\/li>\n<\/ul>\n\n\n\n<p>Der erste Eintrag soll nun etwas genauer unter die Lupe genommen werden\u2026<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>[#[0;32m OK #[0m] Started Tell Plymouth To Write Out Runtime Data.<\/li>\n<\/ul>\n\n\n\n<p>Auch f\u00fcr mich ist vieles hier jetzt Neuland. Die \u201eStatusmeldung\u201c (hier OK) ist die erste Angabe mit der ich etwas anfangen kann \u2013 und \u201eOK\u201c klingt immer gut. Ob es sich bei \u201e0,32m\u201c um einen Zeitindex handelt, kann ich nur vermuten. Allerdings finde ich es merkw\u00fcrdig, dass alle Eintr\u00e4ge in boot.log diesen Wert ausgeben. Die Beschreibung des Vorgangs finde ich dann wieder interessanter. Dem Dienst oder dem Programm \u201ePlymouth\u201c wurde also erfolgreich mitgeteilt, seine Laufzeit-Daten auszuschreiben\u2026Zugegeben sicher eine etwas holperige \u00dcbersetzung. Was das im Detail bedeutet wei\u00df ich auch nicht\u2026Was ich aber mitteilen kann ist, dass \u201ePlymouth\u201c f\u00fcr den Boot-Splash zust\u00e4ndig ist, also f\u00fcr die grafische Animation w\u00e4hrend des Startvorgangs. Setzen wir nun unsere Entdeckungsreise in der boot.log fort, fallen uns noch folgende Eintr\u00e4ge auf:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Started Raise network interfaces<\/li>\n\n\n\n<li>Reached target Sound Card<\/li>\n\n\n\n<li>Listening on CUPS Scheduler<\/li>\n<\/ul>\n\n\n\n<p>Es finden sich noch viele andere interessante Eintr\u00e4ge in dieser Datei. Doch die drei genannten Beispiele zeigen schon gut das Grundprinzip. Drei verschiedene Zust\u00e4nde werden hier wohl schon sichtbar\u2026<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Vorgang wird gestartet (started)<\/li>\n\n\n\n<li>Vorgang hat sein Ziel erreicht (reached target)<\/li>\n\n\n\n<li>Vorgang wartet auf Anfrage (listening)<\/li>\n<\/ul>\n\n\n\n<p>\u00dcbertragen auf die genannten Beispiele hei\u00dft das: Der Vorgang f\u00fcr die Netzwerk-Schnittstelle wurde gestartet, die Soundkarte hat ihr Ziel erreicht und ist somit einsatzbereit und der CUPS-Sheduler (ich vermute die Drucker-Warteschlange) wartet auf Anfragen\u2026<\/p>\n\n\n\n<p><strong>Der dmesg-Befehl:<\/strong><\/p>\n\n\n\n<p>Es gibt auch Vorg\u00e4nge beim Systemstart die sind einfach noch zu fr\u00fch um schon in ein Protokoll geschrieben zu werden. Dazu gibt es den Befehl dmesg, der die Kernel-Meldungen ausgibt\u2026 Das was man als Ausgabe von dmesg bekommt ist aber gr\u00f6\u00dftenteils unverst\u00e4ndlicher \u201eTechnobabbel\u201c. Fehlermeldungen werden in roter Schrift hervorgehoben und das sch\u00f6ne Internet hilft dann eventuell bei der Korrektur\u2026<\/p>\n\n\n\n<p><strong>Visualisierung des Startvorgangs:<\/strong><\/p>\n\n\n\n<p>Mit \u201ebootchart\u201c l\u00e4sst sich der Startvorgang auch visualisieren. Auch eine Art von Protokollierung die hier vorgestellt werden soll\u2026:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>systemd-analyze plot > bootchart.svg<\/li>\n<\/ul>\n\n\n\n<p>Im Ergebniss entsteht eine Grafikdatei die den Startvorgang mit einem Zeitindex als Balkengrafik anzeigt\u2026 Dieser Grafik ist zu entnehmen, dass ganz am Anfang der Kernel startet und dann systemd. Der Startvorgang wird dann mit \u201emount\u201c fortgesetzt und so weiter und so weiter\u2026<\/p>\n\n\n\n<p><strong>Systemprotokollierung von Updates und Upgrades:<\/strong><\/p>\n\n\n\n<p>Eine Datei \u201eupdate.log\u201c oder \u201eupgrade.log\u201c findet sich leider nicht direkt im Ordner var\/log\u2026Doch es findet sich ein Unterordner \u201edist.upgrade\u201c. Leider sind die Dateien die sich hier befinden auch nicht die Art von Protokollen auf die ich gehofft hatte\u2026 In der history.log findet sich nur ein Start- und ein End-Datum f\u00fcr was auch immer. Worauf sich diese beiden Eintr\u00e4ge beziehen bleibt mir ein R\u00e4tsel. In der main.log.partial finden sich nur \u00e4ltere Eintr\u00e4ge \u2013 was f\u00fcr ein Upgrade ja vermutlich sogar noch zeitlich passt. Doch wo sind die Updates protokolliert? F\u00fcndig geworden bin ich dann im Unterordner \u201eapt\u201c und dort findet sich eine weitere history.log-Datei\u2026Es scheint aber so, dass dort immer nur die letzte Aktualisierung eingetragen wird\u2026 F\u00fcr Firefox findet sich beispielsweise folgender Eintrag in der var\/log\/apt\/history.log-Datei:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>firefox:i386 (66.0.1+build1-0ubuntu0.18.04.1, 66.0.2+build1-0ubuntu0.18.04.1)<\/li>\n<\/ul>\n\n\n\n<p>Firefox wurde also von Version 66.0.1 auf Version 66.0.2 aktualisiert.<\/p>\n\n\n\n<p><strong>Systemd und das Journal:<\/strong><\/p>\n\n\n\n<p>Im n\u00e4chsten Artikel gibt es Infos zur Systemprotokollierung mit systemd und dem Journal\u2026<\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>F\u00fcr diesen Artikel interessiert uns die Systemprotokollierung des Bootvorganges und von Updates und Upgrades\u2026<\/p>\n","protected":false},"author":1,"featured_media":791,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[21],"class_list":["post-2586","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","tag-linux-gruppe-peine"],"_links":{"self":[{"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/posts\/2586","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/comments?post=2586"}],"version-history":[{"count":1,"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/posts\/2586\/revisions"}],"predecessor-version":[{"id":2587,"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/posts\/2586\/revisions\/2587"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/media\/791"}],"wp:attachment":[{"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/media?parent=2586"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/categories?post=2586"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fuhselab.de\/index.php\/wp-json\/wp\/v2\/tags?post=2586"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}