One place for hosting & domains

      Verwenden von Journalctl zum Anzeigen und Manipulieren von Systemd-Protokollen


      Einführung

      Einige der überzeugendsten Vorteile von systemd sind diejenigen, die mit der Prozess- und Systemprotokollierung verbunden sind. Bei der Verwendung anderer Tools werden Protokolle normalerweise im gesamten System verteilt, von verschiedenen Daemons und Prozessen bearbeitet und können ziemlich schwer zu interpretieren, wenn sie sich über mehrere Anwendungen erstrecken. Systemd versucht, diese Probleme zu lösen, indem es eine zentralisierte Verwaltungslösung zur Protokollierung aller Kernel- und Userland-Prozesse bereitstellt. Das System, das diese Protokolle sammelt und verwaltet, wird als Journal bezeichnet.

      Das Journal wird mit dem Daemon journald implementiert, der alle vom Kernel, initrd, services etc. erzeugten Nachrichten verarbeitet. In diesem Leitfaden besprechen wir die Verwendung des Dienstprogramms journalctl, mit dem Sie auf die in dem Journal gespeicherten Daten zugreifen und diese manipulieren können.

      Allgemeiner Gedanke

      Eine der Triebfedern hinter dem Journal systemd ist die Zentralisierung der Verwaltung von Protokollen, unabhängig davon, woher die Nachrichten stammen. Da ein Großteil des Boot-Prozesses und der Verwaltung von Diensten durch den Prozess systemd abgewickelt wird, ist es sinnvoll, die Art und Weise, wie Protokolle gesammelt und darauf zugegriffen wird, zu standardisieren. Der Daemon journald sammelt Daten aus allen verfügbaren Quellen und speichert sie in einem Binärformat für einfache und dynamische Manipulation.

      Dies bringt eine Reihe von bedeutenden Vorteilen mit sich. Durch die Interaktion mit den Daten über ein einziges Dienstprogramm sind Administratoren in der Lage, Protokolldaten dynamisch nach ihren Bedürfnissen anzuzeigen. Dies kann so einfach sein, wie das Anzeigen der Boot-Daten von vor drei Boot-Vorgängen oder das Kombinieren der Protokolleinträge von zwei verwandten Diensten nacheinander, um ein Kommunikationsproblem zu beheben.

      Das Speichern der Protokolldaten in einem Binärformat bedeutet auch, dass die Daten in beliebigen Ausgabeformaten angezeigt werden können, je nachdem, was Sie gerade benötigen. Für die tägliche Protokollverwaltung sind Sie eventuell daran gewöhnt, die Protokolle im Standard-Format syslog anzuzeigen, aber wenn Sie sich später entscheiden, Dienstunterbrechungen grafisch darzustellen, können Sie jeden Eintrag als JSON-Objekt ausgeben, um ihn für Ihren grafischen Dienst konsumierbar zu machen. Da die Daten nicht im Klartext auf die Festplatte geschrieben werden, ist keine Konvertierung erforderlich, wenn Sie ein anderes On-Demand-Format benötigen.

      Das Journal systemd kann entweder mit einer vorhandenen syslog-Implementierung verwendet werden oder es kann die Funktionalität syslog ersetzen, je nach Ihren Bedürfnissen. Während das Journal systemd die meisten Protokollierungsanforderungen von Administratoren abdeckt, kann es auch bestehende Protokollierungsmechanismen ergänzen. Sie haben vielleicht einen zentralisierten syslog-Server, den Sie verwenden, um Daten von mehreren Servern zu kompilieren, aber Sie möchten die Protokolle auch von mehreren Diensten auf einem einzigen System mit dem Journal systemd zusammenführen. Sie können beides tun, indem Sie diese Technologien kombinieren.

      Einstellen der Systemzeit

      Einer der Vorteile der Verwendung eines binären Journals für die Protokollierung ist die Fähigkeit, Protokolldatensätze in UTC oder lokaler Zeit anzuzeigen. Standardmäßig zeigt systemd Ergebnisse in der lokalen Zeit an.

      Aus diesem Grund stellen wir, bevor wir mit dem Journal beginnen, sicher, dass die Zeitzone korrekt eingestellt ist. Die Suite systemd verfügt über ein Tool namens timedatectl, das dabei helfen kann.

      Sehen Sie zuerst nach, welche Zeitzonen mit der Option list-timezones verfügbar sind:

      timedatectl list-timezones
      

      Dadurch werden die auf Ihrem System verfügbaren Zeitzonen aufgelistet. Wenn Sie diejenige gefunden haben, die dem Standort Ihres Servers entspricht, können Sie sie mit der Option set-timezone einstellen:

      sudo timedatectl set-timezone zone
      

      Um sicherzustellen, dass Ihr Rechner jetzt die richtige Zeit verwendet, verwenden Sie den Befehl timedatectl allein oder mit der Option status. Die Anzeige wird die gleiche sein:

      timedatectl status
      
            Local time: Thu 2015-02-05 14:08:06 EST
        Universal time: Thu 2015-02-05 19:08:06 UTC
              RTC time: Thu 2015-02-05 19:08:06
             Time zone: America/New_York (EST, -0500)
           NTP enabled: no
      NTP synchronized: no
       RTC in local TZ: no
            DST active: n/a
      

      In der ersten Zeile sollte die korrekte Zeit angezeigt werden.

      Grundlegendes Anzeigen von Protokollen

      Um die Protokolle zu sehen, die der Daemon journald gesammelt hat, verwenden Sie den Befehl journalctl.

      Bei alleiniger Verwendung wird jeder im System vorhandene Journaleintrag innerhalb eines Pager (normalerweise less) angezeigt, damit Sie durchsuchen können. Die ältesten Einträge werden oben angezeigt:

      journalctl
      
      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
      Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules
      
      . . .
      

      Sie werden wahrscheinlich seitenweise Daten durchblättern müssen, die zehn- oder hunderttausende Zeilen lang sein können, wenn sich systemd schon lange auf Ihrem System befindet. Dies demonstriert, wie viele Daten in der Journal-Datenbank vorhanden sind.

      Das Format wird denjenigen vertraut sein, die an die Standard-Protokollierung syslog gewöhnt sind. Allerdings werden hier tatsächlich Daten aus mehr Quellen gesammelt als traditionelle syslog-Implementierungen in der Lage sind. Es beinhaltet Protokolle des frühen Boot-Prozesses, des Kernel, der initrd und der Anwendungsstandardfehler und -ausgänge. Diese sind alle im Journal verfügbar.

      Vielleicht fällt Ihnen auf, dass alle angezeigten Zeitstempel in lokaler Zeit sind. Dies ist für jeden Protokolleintrag verfügbar, da die lokale Zeit auf unserem System korrekt eingestellt ist. Alle Protokolle werden mit dieser neuen Information angezeigt.

      Wenn Sie die Zeitstempel in UTC anzeigen möchten, können Sie das Flag --utc verwenden:

      journalctl --utc
      

      Journal-Filterung nach Zeit

      Obwohl der Zugriff auf eine so große Datensammlung durchaus nützlich ist, kann es schwierig oder unmöglich sein, eine so große Menge mental zu untersuchen und zu verarbeiten. Aus diesem Grund ist eine der wichtigsten Funktionen von journalctl seine Filteroptionen.

      Anzeigen von Protokollen aus dem aktuellen Boot

      Die grundlegendste dieser Optionen, die Sie möglicherweise täglich verwenden, ist das Flag -b. Damit werden Ihnen alle Journaleinträge angezeigt, die seit dem neuesten Neustart gesammelt wurden.

      journalctl -b
      

      Dies hilft Ihnen, Informationen zu identifizieren und zu verwalten, die für Ihre aktuelle Umgebung relevant sind.

      In Fällen, in denen Sie diese Funktion nicht verwenden und mehr als einen Tag von Bootvorgängen anzeigen, werden Sie sehen, dass journalctl eine Zeile eingefügt hat, die so aussieht, wann immer das System heruntergefahren wurde:

      . . .
      
      -- Reboot --
      
      . . .
      

      Dies kann verwendet werden, um Ihnen dabei zu helfen, die Informationen logisch in Boot-Sitzungen aufzuteilen.

      Vergangene Bootvorgänge

      Während Sie in der Regel die Informationen aus dem aktuellen Bootvorgang anzeigen möchten, gibt es sicherlich Zeiten, in denen auch vergangene Bootvorgänge hilfreich sind. Das Journal kann Informationen von vielen vorherigen Bootvorgängen speichern, sodass journalctl eingestellt werden kann, um Informationen einfacher anzuzeigen.

      Bei einigen Distributionen ist das Speichern von Informationen zu früheren Bootvorgängen standardmäßig aktiviert, bei anderen ist diese Funktion deaktiviert. Um persistente Boot-Informationen zu aktivieren, können Sie entweder das Verzeichnis zum Speichern des Journals erstellen, indem Sie Folgendes eingeben:

      • sudo mkdir -p /var/log/journal

      Oder Sie können die Journal-Konfigurationsdatei bearbeiten:

      • sudo nano /etc/systemd/journald.conf

      Setzen Sie unter dem Abschnitt [Journal] die Option Storage= auf „persistent“, um die persistente Protokollierung zu aktivieren:

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Wenn das Speichern von vorherigen Bootvorgängen auf Ihrem Server aktiviert ist, stellt journalctl einige Befehle bereit, um Ihnen die Arbeit mit Bootvorgängen als Einheit der Division zu erleichtern. Um die Bootvorgänge zu sehen, von denen journald weiß, verwenden Sie die Option --list-boots mit journalctl:

      journalctl --list-boots
      
      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
      -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
       0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
      

      Dies zeigt eine Zeile für jeden Bootvorgang an. Die erste Spalte ist der Offset für den Bootvorgang, der verwendet werden kann, um den Bootvorgang mit journalctl einfach zu referenzieren. Wenn Sie eine absolute Referenz benötigen, steht die Boot-ID in der zweiten Spalte. Die Zeit, auf die sich die Boot-Sitzung bezieht, erkennen Sie an den beiden Zeitangaben, die am Ende aufgeführt sind.

      Um Informationen von diesen Bootvorgängen anzuzeigen, können Sie entweder Informationen aus der ersten oder zweiten Spalte verwenden.

      Um beispielsweise das Journal von dem vorherigen Boot zu sehen, verwenden Sie den relativen Zeiger -1 mit dem Flag -b:

      journalctl -b -1
      

      Zum Abrufen von Daten aus einem Boot können Sie auch die Boot-ID verwenden:

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Zeitfenster

      Während es unglaublich nützlich ist, Protokolleinträge nach Bootvorgang zu sehen, möchten Sie vielleicht oft Zeitfenster abfragen, die nicht gut mit Systemstarts übereinstimmen. Dies kann besonders bei lang laufenden Servern mit erheblicher Betriebszeit der Fall sein.

      Sie können nach beliebigen Zeitgrenzen filtern, indem Sie die Optionen --since und --until verwenden, die die angezeigten Einträge auf diejenigen nach bzw. vor der angegebenen Zeit einschränken.

      Die Zeitwerte können in einer Vielzahl von Formaten vorliegen. Für absolute Zeitwerte sollten Sie das folgende Format verwenden:

      YYYY-MM-DD HH:MM:SS
      

      Beispielsweise können wir alle Einträge seit dem 10. Januar 2015 um 17:15 Uhr sehen, indem wir eingeben:

      journalctl --since "2015-01-10 17:15:00"
      

      Wenn Komponenten des obigen Formats weggelassen werden, werden einige Standardwerte angewendet. Wenn beispielsweise das Datum weggelassen wird, wird das aktuelle Datum angenommen. Wenn die Zeitkomponente fehlt, wird „00:00:00“ (Mitternacht) ersetzt. Das Sekundenfeld kann auch weggelassen werden, sodass standardmäßig „00“ verwendet wir:

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"
      

      Das Journal versteht auch einige relative Werte und benannte Abkürzungen. Beispielsweise können Sie die Wörter „gestern“, „heute“, „morgen“ oder „jetzt“ verwenden. Relative Zeiten geben Sie an, indem Sie einem nummerierten Wert ein „-“ oder „+“ voranstellen oder Wörter wie „vor“ in einem Satzbau verwenden.

      Um die Daten von gestern zu erhalten, könnten Sie eingeben:

      journalctl --since yesterday
      

      Wenn Sie Berichte über eine Dienstunterbrechung erhalten haben, die um 9:00 Uhr begann und bis vor einer Stunde andauerte, könnten Sie eingeben:

      journalctl --since 09:00 --until "1 hour ago"
      

      Wie Sie sehen können, ist es relativ einfach, flexible Zeitfenster zu definieren, um die Einträge zu filtern, die Sie sehen möchten.

      Filtern nach Nachrichteninteresse

      Wir haben vorstehend einige Möglichkeiten kennengelernt, wie Sie die Journaldaten anhand von Zeiteinschränkungen filtern können. In diesem Abschnitt werden wir besprechen, wie Sie basierend auf dem Dienst oder der Komponente filtern können, an der Sie interessiert sind. Das Journal systemd bietet eine Vielzahl von Möglichkeiten, dies zu tun.

      Nach Einheit

      Die vielleicht nützlichste Art der Filterung ist nach der Einheit, an der Sie interessiert sind. Wir können die Option -u verwenden, um auf diese Weise zu filtern.

      Um beispielsweise alle Protokolle einer Nginx-Einheit auf unserem System zu sehen, können wir eingeben:

      journalctl -u nginx.service
      

      Normalerweise würden Sie wahrscheinlich auch nach der Zeit filtern wollen, um die Zeilen anzuzeigen, an denen Sie interessiert sind. Um beispielsweise zu überprüfen, wie der Dienst heute ausgeführt wird, können Sie eingeben:

      journalctl -u nginx.service --since today
      

      Diese Art der Fokussierung wird extrem hilfreich, wenn Sie die Fähigkeit des Journals nutzen, Datensätze aus verschiedenen Einheiten zusammenzuführen. Wenn Ihr Nginx-Prozess beispielsweise mit einer PHP-FPM-Einheit verbunden ist, um dynamischen Inhalt zu verarbeiten, können Sie die Einträge von beiden in chronologischer Reihenfolge zusammenführen, indem Sie beide Einheiten angeben:

      journalctl -u nginx.service -u php-fpm.service --since today
      

      Dies kann es wesentlich einfacher machen, die Interaktionen zwischen verschiedenen zu erkennen und System zu debuggen, anstatt einzelne Prozesse.

      Nach Prozess, Benutzer oder Gruppen-ID

      Einige Dienste spawnen eine Vielzahl von untergeordneten Prozesse, um die Arbeit zu erledigen. Wenn Sie die genaue PID des Prozesses, an dem Sie interessiert sind, ausgekundschaftet haben, können Sie auch nach dieser filtern.

      Dazu können wir durch Angabe des Feldes _PID filtern. Wenn die PID, an der wir interessiert sind, beispielsweise 8088 ist, könnten wir eingeben:

      journalctl _PID=8088
      

      Zu anderen Zeiten möchten Sie möglicherweise alle Einträge anzeigen, die von einem bestimmten Benutzer oder einer Gruppe protokolliert wurden. Dies kann mit den Filtern _UID oder _GID geschehen. Wenn Ihr Webserver beispielsweise unter dem Benutzer www-data läuft, können Sie die Benutzer-ID finden, indem Sie eingeben:

      id -u www-data
      
      33
      

      Anschließend können Sie die zurückgegebene ID verwenden, um die Journalergebnisse zu filtern:

      journalctl _UID=33 --since today
      

      Das Journal systemd hat viele Felder, die für die Filterung verwendet werden können. Einige davon werden von dem zu protokollierenden Prozess übergeben und einige werden von journald anhand von Informationen angewendet, die es zum Zeitpunkt der Protokollierung aus dem System sammelt.

      Der führende Unterstrich gibt an, dass das Feld _PID von dem letzteren Typ ist. Das Journal zeichnet automatisch die PID des protokollierenden Prozesses auf und indexiert sie für spätere Filterungen. Sie können sich über alle verfügbaren Journalfelder informieren, indem Sie eingeben:

      man systemd.journal-fields
      

      Wir werden einige davon in diesem Leitfaden besprechen. Für den Moment werden wir jedoch eine weitere nützliche Option bespreche, die mit der Filterung nach diesen Feldern zu tun hat. Die Option -F kann verwendet werden, um alle verfügbaren Werte für ein bestimmtes Journalfeld anzuzeigen.

      Um beispielsweise zu sehen, für welche Gruppen-IDs das Journal systemd Einträge aufweist, können Sie eingeben:

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Dies zeigt Ihnen alle Werte, die das Journal für das Feld Gruppen-ID gespeichert hat. Dies kann Ihnen beim Erstellen Ihrer Filter helfen.

      Nach Komponentenpfad

      Wir können auch filtern, indem wir eine Pfadposition bereitstellen.

      Wenn der Pfad zu einer ausführbaren Datei führt, zeigt journalctl alle Einträge an, die die betreffende ausführbare Datei betreffen. Um beispielsweise die Einträge zu finden, die die ausführbare Datei bash betreffen, können Sie eingeben:

      journalctl /usr/bin/bash
      

      Wenn eine Einheit für die ausführbare Datei verfügbar ist, ist diese Methode sauberer und bietet bessere Informationen (Einträge aus zugehörigen untergeordneten Prozessen usw.). Manchmal ist dies jedoch nicht möglich.

      Anzeigen von Kernel-Meldungen

      Kernel-Meldungen, die normalerweise in der Ausgabe dmesg zu finden sind, können ebenfalls aus dem Journal abgerufen werden.

      Um nur diese Meldungen anzuzeigen, können wir die Flags -k oder --dmesg zu unserem Befehl hinzufügen:

      journalctl -k
      

      Standardmäßig werden damit die Kernel-Meldungen des aktuellen Bootvorgangs angezeigt. Sie können einen alternativen Bootvorgang angeben, indem Sie die zuvor besprochenen Boot-Auswahl-Flags verwenden. Um beispielsweise die Meldungen von vor fünf Bootvorgängen zu erhalten, könnten Sie eingeben:

      journalctl -k -b -5
      

      Nach Priorität

      Ein Filter, an dem Systemadministratoren oft interessiert sind, ist die Meldungspriorität. Während es oft nützlich ist, Informationen auf einem sehr ausführlichen Niveau zu protokollieren, können Protokolle mit niedriger Priorität beim tatsächlichen Verarbeiten der verfügbaren Informationen ablenken und verwirrend sein.

      Sie können journalctl verwenden, um nur Meldungen einer bestimmten Priorität oder höher anzuzeigen, indem Sie die Option -p verwenden. Dadurch können Sie Meldungen mit niedrigerer Priorität herausfiltern.

      Um beispielsweise nur Einträge anzuzeigen, die auf der Fehlerebene oder höher protokolliert wurden, können Sie eingeben:

      journalctl -p err -b
      

      Dies zeigt Ihnen alle Meldungen an, die als Fehler, kritisch, Alarm oder Notfall gekennzeichnet sind. Das Journal implementiert die Standard-syslog-Meldungsebenen. Sie können entweder den Namen der Priorität oder den entsprechenden numerischen Wert verwenden. In der Reihenfolge von höchster bis niedrigster Priorität sind dies:

      • 0: emerg (Notfall)
      • 1: alert (Alarm)
      • 2: crit (kritisch)
      • 3: err (Fehler)
      • 4: warning (Warnung)
      • 5: notice (Hinweis)
      • 6: info (Information)
      • 7: debug (Fehlersuche)

      Die vorstehenden Zahlen oder Namen können austauschbar mit der Option -p verwendet werden. Wenn Sie die Priorität auswählen, werden Meldungen angezeigt, die auf der angegebenen Ebene markiert sind, und solche, die darüber liegen.

      Ändern der Journalanzeige

      Vorstehend haben wir die Auswahl von Einträgen durch Filterung demonstriert. Es gibt jedoch noch andere Möglichkeiten, die Ausgabe zu ändern. Wir können die Anzeige journalctl an verschiedene Bedürfnisse anpassen.

      Kürzen oder Erweitern der Ausgabe

      Wir können anpassen, wie journalctl Daten anzeigt, indem wir ihn anweisen, die Ausgabe zu verkürzen oder zu erweitern.

      Standardmäßig zeigt journalctl den gesamten Eintrag in dem Pager an und lässt die Einträge rechts am Bildschirm auslaufen. Auf diese Informationen können Sie durch Drücken der rechten Pfeiltaste zugreifen.

      Wenn Sie die Ausgabe lieber gekürzt haben möchten, wobei an den Stellen, an denen Informationen entfernt wurden, eine Ellipse eingefügt wird, können Sie die Option --no-full verwenden:

      journalctl --no-full
      
      . . .
      
      Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
      Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
      Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
      

      Sie können damit auch in die entgegengesetzte Richtung gehen und journalctl anweisen, alle Informationen anzuzeigen, unabhängig davon, ob sie nicht druckbare Zeichen enthält. Wir können dies mit dem Flag -a tun:

      journalctl -a
      

      Ausgabe auf Standardausgabe

      Standardmäßig zeigt journalctl die Ausgabe in einem Pager an, um den Konsum zu erleichtern. Wenn Sie jedoch vorhaben, die Daten mit Textmanipulationswerkzeugen zu verarbeiten, möchten Sie wahrscheinlich in der Lage sein, auf die Standardausgabe auszugeben.

      Sie können dies mit der Option --no-pager tun:

      journalctl --no-pager
      

      Dies kann direkt in ein Verarbeitungsprogramm geleitet oder in eine Datei auf der Festplatte umgeleitet werden, je nach Ihren Bedürfnissen.

      Ausgabeformate

      Wenn Sie, wie oben erwähnt, Journaleinträge verarbeiten, wird es Ihnen die Analyse der Daten wahrscheinlich leichter fallen, wenn sie in einem besser konsumierbaren Format vorliegen. Glücklicherweise kann das Journal in einer Vielzahl von Formaten angezeigt werden, wenn es erforderlich ist. Dazu können Sie die Option -o mit einem Formatbezeichner verwenden.

      Sie können die Journaleinträge beispielsweise in JSON ausgeben, indem Sie eingeben:

      journalctl -b -u nginx -o json
      
      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
      
      . . .
      

      Dies ist nützlich für das Parsen mit Dienstprogrammen. Sie könnten das Format json-pretty verwenden, um die Datenstruktur besser in den Griff zu bekommen, bevor Sie sie an den JSON-Verbraucher übergeben:

      journalctl -b -u nginx -o json-pretty
      
      {
          "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
          "__REALTIME_TIMESTAMP" : "1422990364739502",
          "__MONOTONIC_TIMESTAMP" : "27200938",
          "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
          "PRIORITY" : "6",
          "_UID" : "0",
          "_GID" : "0",
          "_CAP_EFFECTIVE" : "3fffffffff",
          "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
          "_HOSTNAME" : "desktop",
          "SYSLOG_FACILITY" : "3",
          "CODE_FILE" : "src/core/unit.c",
          "CODE_LINE" : "1402",
          "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
          "SYSLOG_IDENTIFIER" : "systemd",
          "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
          "_TRANSPORT" : "journal",
          "_PID" : "1",
          "_COMM" : "systemd",
          "_EXE" : "/usr/lib/systemd/systemd",
          "_CMDLINE" : "/usr/lib/systemd/systemd",
          "_SYSTEMD_CGROUP" : "/",
          "UNIT" : "nginx.service",
          "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
          "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
      }
      
      . . .
      

      Die folgenden Formate können für die Anzeige verwendet werden:

      • cat: Zeigt nur das Meldungsfeld selbst an.
      • export: Ein Binärformat, das sich zum Übertragen oder Sichern eignet.
      • json: Standard-JSON mit einem Eintrag pro Zeile.
      • json-pretty: JSON, das für eine bessere menschliche Lesbarkeit formatiert ist.
      • json-sse: JSON-formatierte Ausgabe, die eingehüllt ist, um das Hinzufügen von vom Server gesendeten Ereignissen zu ermöglichen.
      • short: Die Standardausgabe im syslog-Stil.
      • short-iso: Das Standardformat, das zum Anzeigen von ISO-8601 Wallclock-Zeitstempeln erweitert wurde.
      • short-monotonic: Das Standardformat mit monotonen Zeitstempeln.
      • short-precise: Das Standardformat mit Mikrosekundengenauigkeit.
      • verbose: Zeigt jedes für den Eintrag verfügbare Journalfeld an, einschließlich derjenigen, die normalerweise intern verborgen sind.

      Mit diesen Optionen können Sie die Journaleinträge in dem Format anzeigen, das Ihren aktuellen Bedürfnissen am besten entspricht.

      Aktive Prozessüberwachung

      Der Befehl journalctl imitiert, wie viele Administratoren tail zur Überwachung der aktiven oder jüngsten Aktivität verwenden. Diese Funktionalität ist in journalctl eingebaut, sodass Sie auf diese Funktionen zugreifen können, ohne eine Pipe zu einem anderen Tool verwenden zu müssen.

      Anzeigen aktueller Protokolle

      Um eine bestimmte Anzahl von Datensätzen anzuzeigen, können Sie die Option -n verwenden, die genau wie tail -n funktioniert.

      Sie zeigt standardmäßig die letzten 10 Einträge an:

      journalctl -n
      

      Sie können die Anzahl der Einträge, die Sie sehen möchten, mit einer Zahl nach dem -n angeben:

      journalctl -n 20
      

      Verfolgen von Protokollen

      Um die Protokolle aktiv zu verfolgen, während sie geschrieben werden, können Sie das Flag -f verwenden. Auch dies funktioniert so, wie Sie es vielleicht erwarten, wenn Sie Erfahrung mit der Verwendung von tail -f haben:

      journalctl -f
      

      Journalwartung

      Vielleicht fragen Sie sich, was es kostet, all die Daten zu speichern, die wir bisher gesehen haben. Außerdem sind Sie vielleicht daran interessiert, einige ältere Protokolle aufzuräumen und Speicherplatz freizugeben.

      Ermitteln der aktuellen Festplattenbelegung

      Sie können herausfiden, wie viel Platz das Journal derzeit auf der Festplatte belegt, indem Sie das Flag --disk-usage verwenden:

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Löschen alter Protokolle

      Wenn Sie Ihr Journal verkleinern möchten, können Sie dies auf zwei verschiedene Arten tun (verfügbar mit systemd Version 218 und höher).

      Wenn Sie die Option --vacuum-size verwenden, können Sie Ihr Journal durch Angabe einer Größe verkleinern. Dadurch werden alte Einträge entfernt, bis der gesamte auf der Festplatte belegte Journal-Speicherplatz die angeforderte Größe erreicht hat:

      sudo journalctl --vacuum-size=1G
      

      Eine weitere Möglichkeit, das Journal zu verkleinern, ist die Angabe einer Sperrzeit mit der Option --vacuum-time. Alle Einträge, die über diese Zeit hinausgehen, werden gelöscht. Dadurch können Sie die Einträge behalten, die nach einer bestimmten Zeit erstellt wurden.

      Um beispielsweise Einträge aus dem letzten Jahr zu behalten, können Sie eingeben:

      sudo journalctl --vacuum-time=1years
      

      Begrenzen der Journal-Erweiterung

      Sie können Ihren Server so konfigurieren, dass er den Speicherplatz, den das Journal einnehmen kann, begrenzt. Dies kann durch die Bearbeitung der Datei /etc/systemd/journald.conf erfolgen.

      Die folgenden Einträge können verwendet werden, um das Wachstum des Journals zu begrenzen:

      • SystemMaxUse=: Gibt den maximalen Festplattenplatz an, den das Journal im permanenten Speicher belegen kann.
      • SystemKeepFree=: Gibt den Speicherplatz an, den das Journal beim Hinzufügen von Journaleinträgen im permanenten Speicher frei lassen soll.
      • SystemMaxFileSize=: Kontrolliert, wie große einzelne Journaldateien im persistenten Speicher werden können, bevor sie rotiert werden.
      • RuntimeMaxUse=: Gibt den maximalen Festplattenspeicher an, der im flüchtigen Speicher (innerhalb des Dateisystems /run) verwendet werden kann.
      • RuntimeKeepFree=: Gibt an, wie viel Speicherplatz beim Schreiben von Daten in den flüchtigen Speicher (innerhalb des Dateisystems /run) für andere Verwendungen freigehalten werden soll.
      • RuntimeMaxFileSize=: Gibt an, wie viel Speicherplatz eine einzelne Journaldatei im flüchtigen Speicher (innerhalb des Dateisystems /run) einnehmen kann, bevor sie rotiert wird.

      Durch die Einstellung dieser Werte können Sie kontrollieren, wie journald den Speicherplatz auf Ihrem Server verbraucht und bewahrt. Denken Sie daran, dass SystemMaxFileSize und RuntimeMaxFileSize darauf abzielen, dass archivierte Dateien die angegebenen Grenzen erreichen. Dies ist wichtig zu bedenken, wenn Sie Dateizählungen nach einer Vakuum-Operation interpretieren.

      Zusammenfassung

      Wie Sie sehen können, ist das Journal systemd unglaublich nützlich für das Erfassen und Verwalten Ihrer System- und Anwendungsdaten. Die meiste Flexibilität ergibt sich aus den umfangreichen Metadaten, die automatisch aufgezeichnet werden, und der zentralisierten Natur des Protokolls. Der Befehl journalctl macht es einfach, die erweiterten Funktionen des Journals zu nutzen und umfangreiche Analysen und relationales Debugging verschiedener Anwendungskomponenten durchzuführen.



      Source link

      Verwenden der JavaScript-Fetch-API zum Abrufen von Daten


      Einführung

      Es gab eine Zeit, als XMLHttpRequest verwendet wurde, um API-Anfragen zu erstellen. Es enthielt keine Promises und sorgte nicht für einen sauberen JavaScript-Code. Mit jQuery verwendeten Sie die saubere Syntax mit jQuery.ajax().

      Jetzt verfügt JavaScript über eine eigene integrierte Möglichkeit, API-Anfragen zu erstellen. Dies ist die Fetch-API, ein neuer Standard, um Serveranfragen mit Promises zu erstellen, der aber noch viele andere Funktionen enthält.

      In diesem Tutorial erstellen Sie mit der Fetch-API sowohl GET- als auch POST-Anfragen.

      Voraussetzungen

      Um dieses Tutorial zu absolvieren, benötigen Sie Folgendes:

      Schritt 1 — Erste Schritte mit der Fetch-API-Syntax

      Um die Fetch-API zu verwenden, rufen Sie die Methode fetch auf, die die URL der API als Parameter akzeptiert:

      fetch(url)
      

      Fügen Sie nach der Methode fetch() die Promise-Methode then() ein:

      .then(function() {
      
      })
      

      Die Methode fetch() gibt ein Promise zurück. Wenn das zurückgegebene Promise resolve ist, wird die Funktion innerhalb der Methode then() ausgeführt. Diese Funktion enthält den Code für die Handhabung der von der API empfangenen Daten.

      Fügen Sie unter der Methode then() die Methode catch() ein:

      .catch(function() {
      
      });
      

      Die API, die Sie mit fetch() aufrufen, kann außer Betrieb sein oder es können andere Fehler auftreten. Wenn dies geschieht, wird das Promise reject zurückgegeben. Die Methode catch wird verwendet, um reject zu handhaben. Der Code innerhalb von catch() wird ausgeführt, wenn ein Fehler beim Aufruf der API Ihrer Wahl auftritt.

      Zusammengefasst sieht die Verwendung der Fetch-API wie folgt aus:

      fetch(url)
      .then(function() {
      
      })
      .catch(function() {
      
      });
      

      Mit einem Verständnis der Syntax zur Verwendung der Fetch-API können Sie nun mit der Verwendung von fetch() für eine echte API fortfahren.

      Schritt 2 — Verwenden von Fetch zum Abrufen von Daten aus einer API

      Die folgenden Codebeispiele basieren auf der Random User API. Mithilfe der API erhalten Sie zehn Benutzer und zeigen sie auf der Seite mit Vanilla JavaScript an.

      Die Idee ist, alle Daten von der Random User API zu erhalten und in Listenelementen innerhalb der Liste des Autors anzuzeigen. Beginnen Sie mit der Erstellung einer HTML-Datei und dem Hinzufügen einer Überschrift und einer ungeordneten Liste mit der id der authors:

      <h1>Authors</h1>
      <ul id="authors"></ul>
      

      Fügen Sie nun script-Tags am Ende Ihrer HTML-Datei und verwenden Sie einen DOM-Selektor zum Ergreifen von ul. Verwenden Sie getElementById mit authors als Argument. Denken Sie daran: authors ist die id für die zuvor erstellte ul:

      <script>
      
          const ul = document.getElementById('authors');
      
      </script>
      

      Erstellen Sie eine konstante Variable namens url, die die API enthält, die zehn zufällige Benutzer zurückgibt:

      const url="https://randomuser.me/api/?results=10";
      

      Mit erstellten ul und url ist es an der Zeit, die Funktionen zu erstellen, die zur Erstellung der Listenelemente verwendet werden. Erstellen Sie eine Funktion namens createNode, die einen Parameter namens element aufnimmt:

      function createNode(element) {
      
      }
      

      Wenn createNode später aufgerufen wird, müssen Sie den Namen eines tatsächlichen HTML-Elements übergeben, das erstellt werden soll.

      Fügen Sie innerhalb der Funktion eine Anweisung return hinzu, die element unter Verwendung von document.createElement() zurückgibt:

      function createNode(element) {
          return document.createElement(element);
      }
      

      Sie müssen auch eine Funktion namens append erstellen, die zwei Parameter aufnimmt: parent und el:

      function append(parent, el) {
      
      }
      

      Diese Funktion fügt el an parent mit document.createElement an:

      function append(parent, el) {
          return parent.appendChild(el);
      }
      

      Sowohl createNode als auch append sind einsatzbereit. Rufen Sie nun mit der Fetch-API die Random User API unter Verwendung von fetch() mit url als Argument auf:

      fetch(url)
      
      fetch(url)
        .then(function(data) {
      
          })
        })
        .catch(function(error) {
      
        });
      

      Im obigen Code rufen Sie die Fetch-API auf, und übergeben die URL an die Random User API. Dann wird eine Antwort empfangen. Die Antwort, die Sie erhalten, ist jedoch nicht JSON, sondern ein Objekt mit einer Reihe von Methoden, die je nachdem, was Sie mit den Informationen tun möchten, verwendet werden können. Um das zurückgegebene Objekt in JSON zu konvertieren, verwenden Sie die Methode json().

      Fügen Sie die Methode then() hinzu, die eine Funktion mit einem Parameter namens resp enthält:

      fetch(url)
      .then((resp) => )
      

      Der Parameter resp nimmt den Wert des von fetch(url) zurückgegebenen Objekts an. Verwenden Sie die Methode json(), um resp in JSON-Daten zu konvertieren:

      fetch(url)
      .then((resp) => resp.json())
      

      Die JSON-Daten müssen noch verarbeitet werden. Fügen Sie eine weitere Anweisung then() mit einer Funktion hinzu, die ein Argument namens data aufweist:

      .then(function(data) {
      
          })
      })
      

      Erstellen Sie innerhalb dieser Funktion eine Variable namens authors, die gleich data.results gesetzt wird:

      .then(function(data) {
          let authors = data.results;
      

      Sie sollten für jeden Autor in authors ein Listenelement erstellen, das ein Bild und den Namen des Autors anzeigt. Dafür eignet sich die Methode map() hervorragend:

      let authors = data.results;
      return authors.map(function(author) {
      
      })
      

      Erstellen Sie innerhalb Ihrer Funktion map eine Variable namens li, die gleich createNode mit li (dem HTML-Element) als Argument gesetzt wird:

      return authors.map(function(author) {
          let li = createNode('li');
      })
      

      Wiederholen Sie dies, um ein Element span und ein Element img zu erstellen:

      let li = createNode('li');
      let img = createNode('img');
      let span = createNode('span');
      

      Die API bietet einen Namen für den Autor und ein Bild, das zu diesem Namen gehört. Setzen Sie img.src auf das Bild des Autors:

      let img = createNode('img');
      let span = createNode('span');
      
      img.src = author.picture.medium;
      

      Das Element span sollte den Vor- und Nachnamen des author enthalten. Mit der Eigenschaft innerHTML und der String-Interpolation können Sie dies tun:

      img.src = author.picture.medium;
      span.innerHTML = `${author.name.first} ${author.name.last}`;
      

      Mit dem Bild und dem Listenelement, die zusammen mit dem Element span erstellt wurden, können Sie die zuvor erstellte Funktion append verwenden, um diese Elemente auf der Seite anzuzeigen:

      append(li, img);
      append(li, span);
      append(ul, li);
      

      Da beide Funktionen then() abgeschlossen sind, können Sie nun die Funktion catch() hinzufügen. Diese Funktion protokolliert den potenziellen Fehler auf der Konsole:

      .catch(function(error) {
        console.log(error);
      });
      

      Dies ist der vollständige Code der von Ihnen erstellten Anfrage:

      function createNode(element) {
          return document.createElement(element);
      }
      
      function append(parent, el) {
        return parent.appendChild(el);
      }
      
      const ul = document.getElementById('authors');
      const url="https://randomuser.me/api/?results=10";
      
      fetch(url)
      .then((resp) => resp.json())
      .then(function(data) {
        let authors = data.results;
        return authors.map(function(author) {
          let li = createNode('li');
          let img = createNode('img');
          let span = createNode('span');
          img.src = author.picture.medium;
          span.innerHTML = `${author.name.first} ${author.name.last}`;
          append(li, img);
          append(li, span);
          append(ul, li);
        })
      })
      .catch(function(error) {
        console.log(error);
      });
      

      Sie haben gerade erfolgreich eine GET-Anfrage mit der Random User API und der Fetch-API durchgeführt. Im nächsten Schritt lernen Sie, wie Sie POST-Anfragen ausführen.

      Schritt 3 — Handhaben von POST-Anfragen

      Fetch ist standardmäßig auf GET-Anfragen eingestellt, doch Sie können auch alle anderen Arten von Anfragen verwenden, die Kopfzeilen ändern und Daten senden. Dazu müssen Sie Ihr Objekt festlegen und als zweites Argument der Funktion fetch übergeben.

      Erstellen Sie vor der Erstellung einer POST-Anfrage die Daten, die Sie an die API senden möchten. Dies wird ein Objekt namens data mit dem Schlüssel name und dem Wert Sammy (oder Ihrem Namen) sein:

      const url="https://randomuser.me/api";
      
      let data = {
        name: 'Sammy'
      }
      

      Stellen Sie sicher, dass Sie eine konstante Variable einfügen, die den Link der Random User API enthält.

      Da es sich um eine POST-Anfrage handelt, müssen Sie dies explizit angeben. Erstellen Sie ein Objekt namens fetchData:

      let fetchData = {
      
      }
      

      Dieses Objekt muss drei Schlüssel enthalten: method, body und headers. Der Schlüssel method sollte den Wert 'POST' haben. body sollte gleich dem gerade erstellten Objekt data gesetzt werden. headers sollte den Wert von new Headers() haben:

      let fetchData = {
        method: 'POST',
        body: data,
        headers: new Headers()
      }
      

      Die Schnittstelle Headers ist eine Eigenschaft der Fetch-API, mit der Sie verschiedene Aktionen für HTTP-Anfragen und Antwort-Header durchführen können. Wenn Sie mehr darüber erfahren möchten, finden Sie in diesem Artikel namens Definieren von Routen und HTTP-Anfragemethoden in Express weitere Informationen.

      Mit diesem Code kann die POST-Anfrage unter Verwendung der Fetch-API erstellt werden. Sie schließen url und fetchData als Argumente für Ihre POST-Anfrage fetch ein:

      fetch(url, fetchData)
      

      Die Funktion then() enthält Code, der die vom Random User API-Server empfangene Antwort verarbeitet:

      fetch(url, fetchData)
      .then(function() {
          // Handle response you get from the server
      });
      

      Es gibt auch eine andere Möglichkeit zur Erstellung eines Objekts und der Verwendung der Funktion fetch(). Anstatt ein Objekt wie fetchData zu erstellen, können Sie den Anfragekonstruktor verwenden, um Ihr Anfrageobjekt zu erstellen. Erstellen Sie dazu eine Variable namens request:

      const url="https://randomuser.me/api";
      
      let data = {
        name: 'Sara'
      }
      
      var request =
      

      Die Variable request sollte gleich new Request gesetzt werden. Das Konstrukt new Request nimmt zwei Argumente an: die API-URL (url) und ein Objekt. Das Objekt sollte auch die Schlüssel method, body und headers enthalten, genau wie fetchData:

      var request = new Request(url, {
          method: 'POST',
          body: data,
          headers: new Headers()
      });
      

      Jetzt kann request als einziges Argument für fetch() verwendet werden, da es auch die API-URL enthält:

      fetch(request)
      .then(function() {
          // Handle response we get from the API
      })
      

      Insgesamt sieht Ihr Code wie folgt aus:

      const url="https://randomuser.me/api";
      
      let data = {
        name: 'Sara'
      }
      
      var request = new Request(url, {
          method: 'POST',
          body: data,
          headers: new Headers()
      });
      
      fetch(request)
      .then(function() {
          // Handle response we get from the API
      })
      

      Jetzt kennen Sie zwei Methoden zur Erstellung und Ausführung von POST-Anfragen mit der Fetch-API.

      Zusammenfassung

      Obwohl die Fetch-API noch nicht von allen Browsern unterstützt wird, ist sie eine gute Alternative zu XMLHttpRequest. Wenn Sie lernen möchten, wie Sie Web-APIs mit React aufrufen, lesen Sie diesen Artikel zu diesem Thema.



      Source link

      Verwenden von Rsync zum Synchronisieren von lokalen und entfernten Verzeichnissen


      Einführung

      Rsync, was für „remote sync“ (entfernte Synchronisierung) steht, ist ein Tool zur Synchronisierung von lokalen und entfernten Dateien. Es verwendet einen Algorithmus, der die Menge der kopierten Daten minimiert, indem es nur die Abschnitte von Daten verschiebt, die Änderungen aufweisen.

      In diesem Leitfaden werden wir die grundlegende Verwendung dieses leistungsfähigen Dienstprogramms abdecken.

      Was ist Rsync?

      Rsync ist ein sehr flexibles, netzwerkfähiges Synchronisierungstool. Aufgrund seiner Allgegenwärtigkeit unter Linux- und Unix-ähnlichen Systemen und seiner Beliebtheit als Tool für Systemskripte, ist es in den meisten Linux-Distributionen standardmäßig enthalten.

      Grundlegende Syntax

      Die grundlegende Syntax von rsync ist sehr einfach und funktioniert ähnlich wie ssh, scp und cp.

      Wir erstellen zwei Testverzeichnisse und einige Testdateien mit den folgenden Befehlen:

      • cd ~
      • mkdir dir1
      • mkdir dir2
      • touch dir1/file{1..100}

      Wir haben nun ein Verzeichnis namens dir1 mit 100 leeren Dateien.

      Output

      file1 file18 file27 file36 file45 file54 file63 file72 file81 file90 file10 file19 file28 file37 file46 file55 file64 file73 file82 file91 file100 file2 file29 file38 file47 file56 file65 file74 file83 file92 file11 file20 file3 file39 file48 file57 file66 file75 file84 file93 file12 file21 file30 file4 file49 file58 file67 file76 file85 file94 file13 file22 file31 file40 file5 file59 file68 file77 file86 file95 file14 file23 file32 file41 file50 file6 file69 file78 file87 file96 file15 file24 file33 file42 file51 file60 file7 file79 file88 file97 file16 file25 file34 file43 file52 file61 file70 file8 file89 file98 file17 file26 file35 file44 file53 file62 file71 file80 file9 file99

      Wir haben auch ein leeres Verzeichnis namens dir2.

      Um den Inhalt von dir1 mit dir2 auf demselben System zu synchronisieren, geben Sie Folgendes ein:

      Die Option -r bedeutet rekursiv, das für die Verzeichnissynchronisation erforderlich ist.

      Wir könnten stattdessen auch das Flag -a verwenden:

      Die Option -a ist ein Kombinations-Flag. Sie steht für „Archiv“ und synchronisiert rekursiv und erhält symbolische Links, spezielle und Gerätedateien, Modifizierungszeiten, Gruppe, Eigentümer und Berechtigungen. Sie wird häufiger verwendet als -r und ist normalerweise das, was Sie verwenden möchten.

      Ein wichtiger Hinweis

      Vielleicht haben Sie bemerkt, dass es am Ende des ersten Arguments in den obigen Befehlen einen nachstehenden Schrägstrich (/) gibt:

      Dies ist notwendig, um „den Inhalt von dir1“ zu bezeichnen. Die Alternative ohne den nachstehenden Schrägstrich würde dir1, einschließlich des Verzeichnisses, innerhalb von dir2 platzieren. Dies würde eine Hierarchie erstellen, die wie folgt aussieht:

      Überprüfen Sie immer Ihre Argumente, bevor Sie einen Befehl rsync ausführen. Rsync bietet eine Methode dafür, indem Sie die Optionen -n oder --dry-run übergeben. Das Flag -v (für „verbose“, ausführlich) ist ebenfalls notwendig, um die entsprechende Ausgabe zu erhalten:

      Output

      sending incremental file list ./ file1 file10 file100 file11 file12 file13 file14 file15 file16 file17 file18 . . .

      Vergleichen Sie diese Ausgabe mit der Ausgabe, die wir erhalten, wenn wir den nachgestellten Schrägstrich entfernen:

      Output

      sending incremental file list dir1/ dir1/file1 dir1/file10 dir1/file100 dir1/file11 dir1/file12 dir1/file13 dir1/file14 dir1/file15 dir1/file16 dir1/file17 dir1/file18 . . .

      Hier sehen Sie, dass das Verzeichnis selbst übertragen wird.

      Verwenden von Rsync zum Synchronisieren mit einem Remote-System

      Die Synchronisierung mit einem Remote-System ist trivial, wenn Sie SSH-Zugriff auf den Remote-Rechner haben und rsync auf beiden Seiten installiert ist. Sobald Sie SSH-Zugriff zwischen den beiden Rechnern verifiziert haben, können Sie den Ordner dir1 von früher auf einen Remote-Computer synchronisieren, indem Sie diese Syntax verwenden (beachten Sie, dass wir in diesem Fall das eigentliche Verzeichnis übertragen möchten, daher lassen wir den nachgestellten Schrägstrich weg):

      • rsync -a ~/dir1 username@remote_host:destination_directory

      Dies wird als „push“-Operation bezeichnet, da es ein Verzeichnis vom lokalen System auf ein Remote-System schiebt. Die entgegengesetzte Operation ist „pull“. Sie wird verwendet, um ein Remote-Verzeichnis mit dem lokalen System zu synchronisieren. Wenn das dir1 auf dem Remote-System anstelle unseres lokalen Systems wäre, würde die Syntax lauten:

      • rsync -a username@remote_host:/home/username/dir1 place_to_sync_on_local_machine

      Wie cp und ähnliche Tools ist die Quelle immer das erste Argument, und das Ziel immer das zweite.

      Nützliche Optionen für Rsync

      Rsync bietet viele Optionen zur Änderung des Standardverhaltens des Dienstprogramms. Wir haben bereits einige der notwendigen Flags besprochen.

      Wenn Sie Dateien übertragen, die nicht bereits komprimiert wurden, wie Textdateien, können Sie die Netzwerkübertragung reduzieren, indem Sie mit der Option -z eine Komprimierung hinzufügen:

      • rsync -az source destination

      Das Flag -P ist sehr hilfreich. Es kombiniert die Flags --progress und --partial. Mit dem ersten erhalten Sie eine Fortschrittsleiste für die Übertragungen und mit dem zweiten können Sie unterbrochene Übertragungen wiederaufnehmen:

      • rsync -azP source destination

      Output

      sending incremental file list ./ file1 0 100% 0.00kB/s 0:00:00 (xfer#1, to-check=99/101) file10 0 100% 0.00kB/s 0:00:00 (xfer#2, to-check=98/101) file100 0 100% 0.00kB/s 0:00:00 (xfer#3, to-check=97/101) file11 0 100% 0.00kB/s 0:00:00 (xfer#4, to-check=96/101) . . .

      Wenn wir den Befehl erneut ausführen, erhalten wir eine kürzere Ausgabe, da keine Änderungen vorgenommen wurden. Dies illustriert die Fähigkeit von rsync anhand von Änderungszeiten, um zu ermitteln, ob Änderungen vorgenommen wurden.

      • rsync -azP source destination

      Output

      sending incremental file list sent 818 bytes received 12 bytes 1660.00 bytes/sec total size is 0 speedup is 0.00

      Wir können die Änderungszeit einiger Dateien aktualisieren und sehen, dass rsync auf intelligente Weise nur die geänderten Dateien neu kopiert:

      • touch dir1/file{1..10}
      • rsync -azP source destination

      Output

      sending incremental file list file1 0 100% 0.00kB/s 0:00:00 (xfer#1, to-check=99/101) file10 0 100% 0.00kB/s 0:00:00 (xfer#2, to-check=98/101) file2 0 100% 0.00kB/s 0:00:00 (xfer#3, to-check=87/101) file3 0 100% 0.00kB/s 0:00:00 (xfer#4, to-check=76/101) . . .

      Um zwei Verzeichnisse wirklich synchron zu halten, ist es notwendig, Dateien aus dem Zielverzeichnis zu löschen, wenn sie aus der Quelle entfernt werden. Standardmäßig löscht rsync nichts aus dem Zielverzeichnis.

      Wir können dieses Verhalten mit der Option --delete ändern. Bevor Sie diese Option verwenden, sollten Sie die Option --dry-run verwenden und Tests durchführen, um Datenverlust zu vermeiden:

      • rsync -a --delete source destination

      Wenn Sie bestimmte Dateien oder Verzeichnisse ausschließen möchten, die sich innerhalb eines synchronisierten Verzeichnisses befinden, können Sie dies tun, indem Sie sie in einer kommagetrennten Liste nach der Option --exclude= angeben:

      • rsync -a --exclude=pattern_to_exclude source destination

      Wenn wir ein Muster zum Ausschließen angegeben haben, können wir diesen Ausschluss für Dateien, die einem anderen Muster entsprechen, mit der Option --include= überschreiben.

      • rsync -a --exclude=pattern_to_exclude --include=pattern_to_include source destination

      Schließlich kann die Option --backup von rsync verwendet werden, um Backups von wichtigen Dateien zu speichern. Sie wird in Verbindung mit der Option --backup-dir verwendet, die das Verzeichnis angibt, in dem die Backup-Dateien gespeichert werden sollen.

      • rsync -a --delete --backup --backup-dir=/path/to/backups /path/to/source destination

      Zusammenfassung

      Rsync kann Dateiübertragungen über Netzwerkverbindungen vereinfachen und die lokale Verzeichnissynchronisierung robuster machen. Die Flexibilität von rsync macht es zu einer guten Option für viele verschiedene Operationen auf Dateiebene.

      Wenn Sie rsync beherrschen, können Sie komplexe Backup-Operationen entwerfen und eine feinkörnige Kontrolle darüber erhalten, was und wie übertragen wird.



      Source link