Zastanawiam się, czy systemd-journald jest nową implementacją protokołu syslog, czy raczej używa implementacji syslog, takich jak rsyslog, syslog-ng

Trochę googlowałem, ale nie znalazłem w tym nic przekonującego.

Jeśli chodzi o protokoły, systemd-journald…

• … Jest odbiornikiem w gnieździe strumienia o nazwie /run/systemd/journal/stdout. systemd łączy surowe standardowe dane wyjściowe i błędy usług (które domyślnie lub jawnie mają StandardOutput=journal/ StandardError=journal) do tego gniazda. W ten sposób odbiera protokół rekordów w dowolnym formacie o zmiennej długości zakończonych liniami.
• … To słuchacz nazwanych gniazd datagramów /run/systemd/journal/dev-log, który jest symbolicznie powiązany /dev/log. Otrzymuje protokół, który syslog()mówi funkcja biblioteki w bibliotece GNU C, połączona z aplikacjami.
• … Próbuje być klientem innej usługi nasłuchującej na gnieździe datagramowym o nazwie /run/systemd/journal/syslog. Odbiera to również protokół, który syslog()mówi funkcja biblioteki w bibliotece GNU C (chociaż systemd-journaldfaktycznie używa innej biblioteki i innej funkcji do jej wypowiedzenia).
• … To czytnik z urządzenia znakowego o nazwie /dev/kmsg. Odbiera to protokół, który mówi jądro Linuksa, który jest protokołem o zmiennej długości, w dużej mierze w dowolnym formacie, rekordów zakończonych podawaniem linii.
• … To słuchacz w gnieździe datagramowym o nazwie /run/systemd/journal/socket. Jest to analogiczne do przypadku biblioteki GNU C, ponieważ aplikacje łączą się z biblioteką, która mówi do tego gniazda pewien protokół; z wyjątkiem tego, że funkcja jest sd_journal_sendv()w bibliotece systemowej C, do której prowadzą aplikacje, a protokół nie jest ustandaryzowany, ale jest protokołem tylko systemowym, zawierającym tablicę par klucz = wartość i opcjonalnie czytelny deskryptor pliku, w każdym datagramie .

Protokół używany przez syslog()funkcję w bibliotece GNU C nie jest ani RFC 5424, ani RFC 3164 i jest faktycznie własnym de facto standardem. To nie jest RFC 5424, ponieważ nie ma prawidłowej ilości białych znaków i myślników oznaczających opcjonalne pola z wartościami NIL. To nie jest RFC 3164, ponieważ ma PROCIDpole zamiast HOSTNAME.

Kilka lat temu systemowy system operacyjny miałby:

• systemd-journaldwykonując wszystkie powyższe (i niektóre rzeczy, które nie mają znaczenia, jeśli chodzi o protokoły ) i będąc serwerem, z którym biblioteka GNU C i biblioteka systemowa C rozmawiają przy użyciu swoich odpowiednich protokołów
• wywoływany opcjonalny program syslog lub rsyslog lub syslog-ng, albo xinetd/ inetd-style, gdy coś próbuje wysłać wiadomości do /run/systemd/journal/sysloggniazda i odbierać go jako otwarty deskryptor pliku, lub jako prosta usługa skonfigurowana do otwierania i nasłuchiwania /run/systemd/journal/syslogza jego pomocą (odpowiednik imuxsockmoduł rsyslog) ; i mówiąc o protokole biblioteki GNU C.
• opcjonalna usługa syslog lub rsyslog lub syslog-ng lub udp-syslog-read nasłuchująca ruchu RFC 5426

Obecnie systemowy system operacyjny ma:

• systemd-journald ponownie wykonując wszystkie powyższe czynności i będąc serwerem, z którym rozmawiają biblioteka GNU C i biblioteka systemd C.
• opcjonalny program rsyslog wywoływany jako usługa prosta, a nie przez gniazdo, które bezpośrednio odczytuje rzeczy z plików dziennika systemowego za pomocą swojego imjournalmodułu
• opcjonalna usługa syslog lub rsyslog lub syslog-ng lub udp-syslog-read nasłuchująca ruchu RFC 5426

Dalsza lektura

• /unix//a/294206/5132