No que diz respeito aos protocolos, systemd-journald…
- … É o ouvinte em um soquete de fluxo chamado
/run/systemd/journal/stdout. O systemd conecta as saídas e erros padrão brutos dos serviços (que foram padronizados ou que possuem explicitamente StandardOutput=journal/ StandardError=journal) nesse soquete. Assim, ele recebe o protocolo de registros de formato livre de comprimento variável terminados com alimentações de linha.
- … É o ouvinte nos soquetes de datagrama nomeados
/run/systemd/journal/dev-log, que é simbolicamente vinculado /dev/log. Isso recebe o protocolo que a syslog()função de biblioteca da biblioteca GNU C, vinculada aos aplicativos, fala.
- … Tenta ser um cliente de outro serviço escutando um soquete de datagrama chamado
/run/systemd/journal/syslog. Isso também recebe o protocolo que a syslog()função de biblioteca na biblioteca GNU C fala (embora systemd-journaldna verdade use outra biblioteca e outra função para falar).
- … É um leitor de um dispositivo de caractere chamado
/dev/kmsg. Isso recebe o protocolo que o kernel Linux fala, que é um protocolo de registros de tamanho variável, em grande parte de formato livre, terminados com feeds de linha.
- … É o ouvinte em um soquete de datagrama chamado
/run/systemd/journal/socket. Isso é análogo ao caso da biblioteca GNU C, em que os aplicativos se vinculam a uma biblioteca que fala um determinado protocolo para esse soquete; exceto que a função é sd_journal_sendv(), é em uma biblioteca C do systemd que os aplicativos se vinculam e o protocolo não é padronizado, mas é um protocolo somente do sistema que compreende uma matriz de pares chave = valor e, opcionalmente, um descritor de arquivo legível em cada datagrama .
O protocolo falado pela syslog()função na biblioteca GNU C não é o RFC 5424 nem o RFC 3164 e é efetivamente seu próprio padrão de fato. Não é o RFC 5424 porque não possui a quantidade correta de espaços em branco e os traços que designam campos opcionais com valores NIL. Não é o RFC 3164 porque possui um PROCIDcampo em vez de a HOSTNAME.
Há alguns anos, seu sistema operacional systemd teria:
systemd-journaldfazendo todas as opções acima (e algumas coisas que são irrelevantes quando se trata de protocolos ) e sendo o servidor com o qual a biblioteca GNU C e a biblioteca C systemd conversam usando seus respectivos protocolos- um programa syslog ou rsyslog ou syslog-ng opcional chamado, ou
xinetd/ inetd-style quando algo tenta enviar mensagens para /run/systemd/journal/sysloge receber o soquete como um descritor de arquivo aberto ou como um serviço direto configurado para abrir e ouvir /run/systemd/journal/syslogcom ele (equivalente ao imuxsockmódulo rsyslog) ; e falando o protocolo da biblioteca GNU C
- um serviço syslog ou rsyslog ou syslog-ng ou udp-syslog-read opcional que atende ao tráfego RFC 5426
Atualmente, seu sistema operacional systemd possui:
systemd-journald novamente fazendo tudo isso e sendo o servidor com o qual a biblioteca GNU C e a biblioteca systemd C conversam - um programa rsyslog opcional chamado como um serviço direto, e não através de um soquete, que lê diretamente as coisas dos arquivos de diário do systemd usando seu
imjournalmódulo
- um serviço syslog ou rsyslog ou syslog-ng ou udp-syslog-read opcional que atende ao tráfego RFC 5426
Leitura adicional