En lo que respecta a los protocolos, systemd-journald...

... es el oyente en un socket de flujo llamado /run/systemd/journal/stdout. systemd conecta las salidas estándar sin procesar y los errores de los servicios (que se han predeterminado o que tienen explícitamente StandardOutput=journal/ StandardError=journal) a este socket. Por lo tanto, recibe el protocolo de registros de formato libre de longitud variable terminados con saltos de línea.
... es el oyente en los sockets de datagramas llamado /run/systemd/journal/dev-log, que está simbólicamente vinculado desde /dev/log. Esto recibe el protocolo que la syslog()función de la biblioteca en la biblioteca GNU C, vinculada a las aplicaciones, habla.
... intenta ser un cliente de otro servicio que escucha en un socket de datagrama llamado /run/systemd/journal/syslog. Esto también recibe el protocolo que syslog()habla la función de biblioteca en la biblioteca GNU C (aunque en systemd-journaldrealidad usa otra biblioteca y otra función para hablarlo).
... es un lector de un dispositivo de caracteres llamado /dev/kmsg. Esto recibe el protocolo que habla el kernel de Linux, que es un protocolo de longitud variable, en gran parte de formato libre, registros terminados con avances de línea.
... es el oyente en un socket de datagrama llamado /run/systemd/journal/socket. Esto es análogo al caso de la biblioteca GNU C en que las aplicaciones se vinculan a una biblioteca que habla un cierto protocolo a este socket; excepto que la función es sd_journal_sendv(), es en una biblioteca de systemd C a la que se vinculan las aplicaciones, y el protocolo no está estandarizado, sino que es un protocolo solo de systemd que comprende una matriz de pares clave = valor, y opcionalmente un descriptor de archivo legible, en cada datagrama .

El protocolo hablado por la syslog()función en la biblioteca GNU C no es RFC 5424 ni RFC 3164, y es efectivamente su propio estándar de facto. No es RFC 5424 porque no tiene la cantidad correcta de espacios en blanco y los guiones que designan campos opcionales con valores NIL. No es RFC 3164 porque tiene un PROCIDcampo en lugar de un HOSTNAME.

Hace un par de años, su sistema operativo systemd habría tenido:

systemd-journaldhaciendo todo lo anterior (y algunas cosas que son irrelevantes cuando se trata de protocolos ) y ser el servidor con el que la biblioteca GNU C y la biblioteca systemd C hablan utilizando sus respectivos protocolos
Se invoca un programa opcional syslog o rsyslog o syslog-ng, ya sea xinetd/ inetd-style cuando algo intenta enviar mensajes /run/systemd/journal/syslogy recibir el socket como un descriptor de archivo abierto, o como un servicio directo configurado para abrir y escuchar /run/systemd/journal/syslogcon su (equivalente del rsyslog) imuxsockmódulo; y hablando el protocolo de la biblioteca GNU C
un servicio opcional de syslog o rsyslog o syslog-ng o udp-syslog-read para escuchar el tráfico RFC 5426

Hoy en día, su sistema operativo systemd tiene:

systemd-journald de nuevo haciendo todo lo anterior y siendo el servidor con el que hablan la biblioteca GNU C y la biblioteca systemd C
un programa opcional rsyslog invocado como un servicio directo en lugar de a través de un socket, que lee directamente cosas de los archivos de diario de systemd usando su imjournalmódulo
un servicio opcional de syslog o rsyslog o syslog-ng o udp-syslog-read para escuchar el tráfico RFC 5426

Otras lecturas

/unix//a/294206/5132

JdeBP
fuente

¿Es systemd-journald una implementación de syslog?

Respuestas:

Otras lecturas