Como restauro `/ dev / log` no host systemd + rsyslog?

10

No RHEL7, systemd-journaldassume muitas das responsabilidades do que já foi feito por rsyslogd. Seja por bug ou conflito entre esses dois daemons, às vezes /dev/logdesaparecerá. Como resultado, os programas que dependem da syslog(3)chamada não funcionarão corretamente, incluindo, por exemplo logger,. Como posso restaurar o /dev/logsoquete?

systemd-journald rsyslogd

— Otheus
fonte

13

Fazer e responder minha própria pergunta porque o Google não ajudou muito nessa questão.

Normalmente, com rsyslogd, o imuxsockmódulo criará o /dev/logsoquete sozinho, desvinculando a entrada anterior antes de criá-lo. Quando rsyslogdé parado (possivelmente porque a reinicialização falha devido à configuração defeituosa), o rsyslogd é removido /dev/log .

No entanto, RHEL7espera-se que o rsyslog fornecido com ele seja usado em conjunto com systemdo imuxsockmódulo e, na verdade, ele abrirá e removerá o /run/systemd/journal/syslogsoquete. Enquanto isso, o /dev/logdispositivo é criado pelo arquivo de serviço do sistema systemd-journald.socketque é acionado journald.

Aparentemente, independentemente de o $imjournalmódulo ser usado, o seguinte funciona.

Em suma, se /dev/logdesaparecer:

reinicie o systemd-journald.socket:

systemctl restart systemd-journald.socket

depois reinicie o rsyslogd
```
systemctl start rsyslogd
```

ATUALIZAÇÃO: Acredito que restart rsyslogdpode excluir novamente o soquete, se rsyslogdjá estiver em execução.

— Otheus
fonte

2

Muito obrigado por isso! Acabei de perder várias horas rastreando por que o log não estava funcionando para um serviço. Finalmente, localizei o arquivo / dev / log ausente, o que me levou à sua solução.

— Chad Huneycutt

4

A systemctl restart systemd-journald.socket && systemctl restart rsyslogsolução não funcionou para mim no Ubuntu 16.04.

Em vez disso, tive que recriar /dev/logcomo um link simbólico para /run/systemd/journal/dev-log:

ln -s /run/systemd/journal/dev-log /dev/log

— 11181
fonte

Sim, a vinculação manual também deve funcionar. Mas é um pouco difícil de lembrar. Pergunta: No Ubuntu systemd-journald.socketexiste como um serviço? P2: talvez restart rsyslogdo problema tenha sido? Talvez devesse ser simplesmente start rsyslogd?

— Otheus

Q1: sim, existe. Q2: não há restartmais comando, há servicee /etc/init.d/rsyslog.

— 11181 09/03

Por restart rsyslogdeu pensei que estava claro que eu quis dizer systemctl restart rsyslogd. O Ubuntu ainda usa scripts init para rsyslog?

— Otheus

@Otheus /etc/init.d/rsyslog stopseguido por /etc/init.d/rsyslog startnão ajudou. Nem systemctl stop syslog.socket rsyslog.service && systemctl start syslog.socket rsyslog.serviceno meu sistema há ambos /lib/systemd/system/rsyslog.servicee /etc/init.d/rsyslog. De qualquer forma, prefiro não gastar mais tempo com esse problema.

— 11181

0

Para mim, isso acabou sendo um problema de como o módulo imuxsock usado no rsyslog estava trabalhando com o systemd.

Na documentação do imuxsock, eles mostram como o módulo deve funcionar para o systemd. A Etapa 1 foi onde eu estava vendo problemas:

Etapa 1: Selecione o nome do soquete do sistema

Se o usuário não escolheu explicitamente definir SysSock.Use = "off", o nome do soquete do ouvinte padrão (também conhecido como “soquete de log do sistema” ou simplesmente “soquete do sistema”) é definido como / dev / log. Caso contrário, se o usuário tiver definido explicitamente SysSock.Use = "off", o rsyslog não escutará / dev / log OU qualquer soquete definido pelo parâmetro SysSock.Name e o restante desta seção não se aplicará.

Se o usuário especificou sysSock.Name = "/ path / to / custom / socket" (e não definir explicitamente SysSock.Use = "off"), o nome do soquete do ouvinte padrão será substituído por / path / to / custom / socket .

Caso contrário, se o rsyslog estiver sendo executado em systemd AND / run / systemd / journal / syslog ((E o usuário não tiver definido explicitamente SysSock.Use = "off"), o nome do soquete do ouvinte padrão será substituído por / run / systemd / journal / syslog.

O sistema deve ter caído na Etapa 3 e alterado o caminho padrão para "/ run / systemd / journal / syslog", mas permaneceu "/ var / log". Isso significava que o módulo imuxsock tentaria (e terá êxito às vezes) criar um soquete em / dev / log, onde deveria haver um link simbólico criado pelo systemd-journald-dev-log.socket. No caso de falha na criação do soquete real, o link simbólico ainda será removido.

Essa documentação foi o resultado desse problema relatado no rsyslog github. Se você quiser pular a discussão e pular direto para as alterações, consulte PR # 1 e PR # 2, respectivamente.

Minha solução foi apenas configurar o módulo imuxsock para usar o caminho systemd no meu /etc/rsyslog.conf:

module(load="imuxsock"
    SysSock.Name="/run/systemd/journal/syslog")

Isso parece ter corrigido meu problema e parece uma boa solução aqui, pois explicaria por que o link simbólico pode desaparecer novamente depois que você o criou manualmente.

Se você procurar no seu sistema e "/ run / systemd / journal / syslog" não estiver presente, consulte o "syslog.socket" para ver se está iniciando com êxito, pois é o responsável pela criação do soquete.

systemctl status syslog.socket

Pode ser que sua versão do rsyslog.service não defina syslog.service como um alias necessário, pois o syslog.socket tenta ativar esse serviço. Também é possível que vários serviços de registro tentem alias syslog.service, caso em que o último a ser ativado vence.

— Adão
fonte