Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| systemd_journalctl [19/08/2021 - 12:43] – ↷ Seitename wurde von systemd auf systemd_journalctl geändert thommie4 | systemd_journalctl [17/08/2024 - 07:06] (aktuell) – Externe Bearbeitung 127.0.0.1 | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | ====== Systemd Doku ====== | ||
| + | |||
| Doku: [[https:// | Doku: [[https:// | ||
| [[https:// | [[https:// | ||
| - | ====== Logging mit Journalctl ====== | + | ===== Systemctl |
| - | Siehe [[https:// | + | Alle services listen |
| + | < | ||
| - | ===== Boot Vorgänge auflisten ===== | + | systemctl list-units --type=service |
| - | '' | + | </ |
| - | Auflisten aller Boot Vorgänge - 0 ist der neueste | + | Auf " |
| - | '' | + | < |
| + | systemctl list-units --type=service --state=active | ||
| - | Auswählen eines bestimmten Bootvorgangs | + | </ |
| - | Some of the most compelling advantages of systemd are those involved with process and system logging. When using other tools, logs are usually dispersed throughout the system, handled by different daemons and processes, and can be fairly difficult to interpret when they span multiple applications. Systemd attempts to address these issues by providing a centralized management solution for logging all kernel and userland processes. The system that collects and manages these logs is known as the journal. | + | oder Gesamtüberblick über alle, die gerade laufen |
| - | The journal is implemented with the journald daemon, which handles all of the messages produced by the kernel, initrd, services, etc. In this guide, we will discuss how to use the journalctl utility, which can be used to access and manipulate the data held within the journal. General Idea | + | < |
| + | # systemctl list-units --type=service --state=running | ||
| + | OR | ||
| + | # systemctl --type=service --state=running | ||
| - | One of the impetuses behind the systemd journal is to centralize the management of logs regardless of where the messages are originating. Since much of the boot process and service management is handled by the systemd process, it makes sense to standardize the way that logs are collected and accessed. The journald daemon collects data from all available sources and stores them in a binary format for easy and dynamic manipulation. | + | </ |
| - | This gives us a number of significant advantages. By interacting with the data using a single utility, administrators are able to dynamically display log data according to their needs. This can be as simple as viewing the boot data from three boots ago, or combining the log entries sequentially from two related services to debug a communication issue. | + | ===== netstat ===== |
| - | Storing the log data in a binary format also means that the data can be displayed in arbitrary output formats depending on what you need at the moment. For instance, for daily log management you may be used to viewing the logs in the standard syslog format, but if you decide to graph service interruptions later on, you can output each entry as a JSON object to make it consumable to your graphing service. Since the data is not written to disk in plain text, no conversion is needed when you need a different on-demand format. | + | Welche Ports werden benutzt? |
| - | The systemd journal can either be used with an existing syslog implementation, | + | < |
| + | root@radius01: | ||
| + | udp 0 0 0.0.0.0: | ||
| + | udp 0 0 0.0.0.0: | ||
| + | udp 0 0 0.0.0.0: | ||
| + | udp 0 0 0.0.0.0: | ||
| + | udp6 | ||
| + | udp6 | ||
| + | udp6 | ||
| - | One of the benefits of using a binary journal for logging is the ability to view log records in UTC or local time at will. By default, systemd will display results in local time. | + | </ |
| - | Because of this, before we get started with the journal, we will make sure the timezone is set up correctly. The systemd suite actually comes with a tool called timedatectl that can help with this. | + | ===== Journalctl ===== |
| - | First, see what timezones are available with the list-timezones option: | + | Siehe [[https:// |
| - | '' | + | ===== Boot Vorgänge auflisten ===== |
| - | This will list the timezones available on your system. When you find the one that matches the location of your server, you can set it by using the set-timezone option: | + | '' |
| - | '' | + | Auflisten aller Boot Vorgänge |
| - | To ensure that your machine is using the correct time now, use the timedatectl command alone, or with the status option. The display will be the same: | + | '' |
| - | '' | + | Auswählen eines bestimmten Bootvorgangs |
| - | NTP synchronized: | + | Basic Log Viewing |
| - | '' | + | Auflisten der Logs **vor** dem letzten Bootvorgang |
| + | < | ||
| + | '' | ||
| - | The first line should display the correct time. | + | </ |
| + | Dasselbe, aber gefiltert auf kernel logs | ||
| - | ===== Basic Log Viewing ===== | + | < |
| - | To see the logs that the journald daemon has collected, use the journalctl command. | + | </ |
| + | Mit " | ||
| - | When used alone, every journal entry that is in the system will be displayed within a pager (usually less) for you to browse. The oldest entries will be up top: | + | To see the logs that the journald daemon has collected, use the journalctl command. |
| '' | '' | ||
| Zeile 418: | Zeile 437: | ||
| [Unit] Wants=network-online.target After=network.target network-online.target That's for the unit file of your service and for systemd. | [Unit] Wants=network-online.target After=network.target network-online.target That's for the unit file of your service and for systemd. | ||
| + | |||