特定のデバイスの「*.journal」ファイルはどこにありますか?

特定のデバイスの「*.journal」ファイルはどこにありますか?

SSHDのシステムサービスユニットがあります。

$ systemctl status sshd
* ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-09-30 18:54:10 UTC; 6s ago
  Process: 13923 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 13918 ExecReload=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
  Process: 6287 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 6296 (sshd)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/ssh.service
           `-6296 /usr/sbin/sshd -D

Sep 30 18:54:10 machine systemd[1]: Starting OpenBSD Secure Shell server...
Sep 30 18:54:10 machine sshd[6296]: Server listening on 0.0.0.0 port 22.
Sep 30 18:54:10 machine sshd[6296]: Server listening on :: port 22.
Sep 30 18:54:10 machine systemd[1]: Started OpenBSD Secure Shell server.

私は*.journalそれが書くファイルを持っています:

$ find /var/log/journal -type f -name 'system@*.journal' -exec grep -l 'OpenBSD' {} +
/var/log/journal/0123456789abcdef0123456789abcdef/system@0123456789abcdef0123456789abcdef-000000000100bfdd-0005ac0c092a655f.journal
/var/log/journal/0123456789abcdef0123456789abcdef/system@0123456789abcdef0123456789abcdef-000000000102d6c3-0005ac2251abe7d9.journal
/var/log/journal/0123456789abcdef0123456789abcdef/system@0123456789abcdef0123456789abcdef-00000000010fc6d5-0005ac9be551a106.journal
/var/log/journal/0123456789abcdef0123456789abcdef/system@0123456789abcdef0123456789abcdef-0000000000e043b9-0005aad981c2d167.journal
/var/log/journal/0123456789abcdef0123456789abcdef/system@0123456789abcdef0123456789abcdef-00000000010d9bf1-0005ac875e1241e7.journal

前者が与えられると、後者をどのように見つけることができますか?

ベストアンサー1

ログファイルは単位ごとにソートされません。仕訳入力を公開する組織には、アイテムに関連付けられたメタデータのみがあります。ログファイルが常に存在するわけではありません/var/run非永続的に構成されている場合は、ログファイルもあります。

特定の単位の仕訳入力を抽出する正しい方法は、以下を使用またはjournalctl -u <unit_name>使用することです。sd-journalアプリケーションプログラミングインターフェース。また、ログはバイナリファイルなので、正確に解析しやすい形式ではありません。ジャーナルの内部形式が安定した仕様に従うかどうかはわかりません。 journalctlあるいは、APIは確かにこれらのファイルを読む方法です。

特定のファイルをバックアップ(またはトラブルシューティングのために送信)するためにこの質問をする場合は、そのファイルをすべて1つの単位として扱う必要があります。


これらのログファイルのファイル命名規則について具体的に質問したので、これを調査するのに時間を費やしました。新しく起動した後は/run/log/journalファイルのみ/run/log/journal/c13e4a2f54334a95891a6a471db3b7e0/system@edd0c14e44a240038601194807d5c28e-0000000000000001-0005b08ccb2c37b3.journal

命名規則を理解するために、次の部分に分けました。

/run/                                  <-- run/var
  log/journal/                         <-- standard location 
    c13e4a2f54334a95891a6a471db3b7e0/  <-- _MACHINE_ID
    system@                            <-- system/user
    edd0c14e44a240038601194807d5c28e-  <-- Some bus/boot/session ID?
    0000000000000001-                  <-- Sequence number (also looks like offsets as 4-KB blocks in hex)
    0005b08ccb2c37b3                   <-- Timestamp (time since epoch in hex)
    .journal                           <-- Extension

しばらくドライブしてみたマシンを見ると、すべてのsystem@*.journalファイルが80Mで、すべてのuser@*.journalファイルが8.0Mです。この一貫したサイズ変更により、ファイルの分割はログの回転だけであることを示唆しています。修正日を見ると、これを確認することもできます(シーケンスを進行しながら日付が増えることがわかります)。


これらのいくつか(たとえば_MACHINE_ID)を特定するために、日記項目に関連する生のメタデータを調べる必要がありました。取得できるよりも多くのメタデータがありますjournalctl。 sd-journal APIを使用してクイックプログラムを作成し、"Hello"サービスから印刷しました。私の日記で次のデータを見つけました。各.xmlファイルとどのくらいのメタデータが関連付けられているのか驚くべきことですprintf

_UID=0
_GID=0
_CAP_EFFECTIVE=3fffffffff
_TRANSPORT=stdout
_STREAM_ID=2ee82c395817429b975770acb1306d11
SYSLOG_IDENTIFIER=counter
_PID=6523
_COMM=counter
_EXE=/usr/local/bin/counter
_CMDLINE=/usr/local/bin/counter
_SYSTEMD_CGROUP=/system.slice/counter.service
_SYSTEMD_UNIT=counter.service
_SYSTEMD_INVOCATION_ID=711962f5d7bf487b9a262b824c297a42
MESSAGE=Hello
PRIORITY=6
SYSLOG_FACILITY=3
_BOOT_ID=bf0d96cbab2144e3a8544b0e8a0eacc6
_MACHINE_ID=c13e4a2f54334a95891a6a471db3b7e0
_HOSTNAME=simswe24
_TRANSPORT=journal
_SELINUX_CONTEXT=unconfined

この問題を調査するために私が書いたsd-journalプログラムに興味があるなら、ここにあります。

// Compile with `gcc journalctl.c -lsystemd`
#include <systemd/sd-journal.h>
#include <stdio.h>
int main()
{
    // Open the log
    sd_journal* journal;

    if ( sd_journal_open(&journal, SD_JOURNAL_LOCAL_ONLY) < 0 )
    {
        return 1; // Couldn't open journal
    }

    // Subscribe to specific logs:
    // Messages from the service itself
    int r = sd_journal_add_match(journal, "_SYSTEMD_UNIT=counter.service", 0);
    r = r ? r : sd_journal_add_disjunction(journal);
    
    // Messages from PID 1 (systemd) about this service
    r = r ? r : sd_journal_add_match(journal, "_PID=1", 0);
    r = r ? r : sd_journal_add_match(journal, "UNIT=counter.service", 0);
    r = r ? r : sd_journal_add_disjunction(journal);

    if ( r < 0 )
    {
        return 1; // Could not subscribe to all journal entries
    }

    r = sd_journal_seek_head(journal);
    if ( r < 0 )
    {
        return 1; // Problem finding the head of the log
    }


    // Read the log
    int skip_seek=1;
    while( skip_seek || (sd_journal_next(journal) > 0 ) ) 
    {
        const void* data = 0;
        size_t length;
        skip_seek = 0;

        sd_journal_restart_data(journal);

        SD_JOURNAL_FOREACH_DATA(journal, data, length)
        {
            printf("%s\n", data);
        };
    }

    sd_journal_close(journal);

    return 0;
}

おすすめ記事