Por que meu diário do systemd não é persistente nas reinicializações?

Question

Estou passando por um problema muito estranho com uma nova imagem do Fedora 21 em uma instância do Linode. Não consigo reproduzi-lo fora do Linode. A questão é que meu diário do systemd não é persistente entre as reinicializações. De acordo com a documentação :

By default, the journal stores log data in /run/log/journal/. Since /run/ is volatile, log data is lost at reboot. To make the data persistent, it is sufficient to create /var/log/journal/ where systemd-journald will then store the data.

Eu verifiquei que / var / log / journal existe e também defini Storage=persistent em /etc/systemd/journald.conf. O diretório de log contém vários dados:

$ du -sh /var/log/journal/
89M /var/log/journal/

O diário, no entanto, contém apenas entradas de log desde a última reinicialização do sistema:

$ journalctl --list-boots
 0 9f6a5a789dd64ec0b067140905e6da86 Thu 2015-03-19 15:08:48 GMT—Thu 2015-03-19 22:14:37 GMT

Mesmo se eu journalctl --flush antes de reiniciar, os logs serão perdidos. Eu suspeito que isso seja um problema com a imagem do Fedora 21 da Linode, e eu abri um ticket de suporte com eles. Enquanto isso, continuo procurando a causa desse problema.

Como posso depurar isso? O que poderia causar isso? O que posso fazer para corrigir isso?

    

Answer 1

A razão para esse comportamento é que o identificador da máquina em /etc/machine-id muda a cada reinicialização. Isso inicia um novo diretório de log sob /var/log/journal . Registros antigos podem ser visualizados com o seguinte comando:

journalctl --merge

Ainda estou investigando a causa da mudança do ID da máquina. O suporte do Linode está ciente do problema. Eu atualizarei esta resposta quando souber mais.

ATUALIZAÇÃO - A causa raiz do problema é simplesmente que o Linode zerou o conteúdo de /etc/machine-id de suas imagens do sistema de arquivos. O resultado é a seguinte cadeia de eventos:

1. O kernel carrega e monta o sistema de arquivos raiz somente leitura
2. systemd, executado a partir do ramdisk inicial, tenta ler /etc/machine-id do sistema de arquivos raiz (o arquivo existe, mas possui zero de conteúdo)
3. O systemd não pode ler o identificador da máquina, mas também não pode escrever um novo, pois o sistema de arquivos raiz é montado como somente leitura
4. montagens systemd tmpfs on /etc/machine-id (Sim, aparentemente você pode montar um sistema de arquivos em um arquivo )
O
5. systemd invoca o systemd-machine-id-setup que gera um ID de máquina aleatório e armazena-o no agora volátil /etc/machine-id
6. O sistema inicializa com um identificador de máquina volátil

Você pode verificar se o seu sistema tem um ID de máquina volátil, em vez de permanente, observando a saída de mount :

$ mount | grep machine-id
tmpfs on /etc/machine-id type tmpfs (ro,mode=755)

O problema é fácil de corrigir: basta escrever um ID de máquina persistente no real /etc/machine-id . No entanto, é mais fácil falar do que fazer, pois não é possível desmontar tmpfs de /etc/machine-id em um sistema em execução. Estes são os passos que eu dei para consertá-lo no Linode:

1. cp /etc/machine-id /etc/machine-id.copy , em seguida, desligue o sistema
2. No Linode Manager, vá até a guia Rescue e inicialize no modo de recuperação
3. Acesse o sistema por meio do console Lish
4. Monte o sistema de arquivos raiz: mount /dev/xvda /mnt
5. Mova a cópia criada no passo 1 para o ID da máquina real: mv /etc/machine-id.copy /etc/machine-id
6. Reinicializar

Tais são as conseqüências de um ID de máquina ausente na inicialização. Espero que isso ajude um transeunte aleatório no futuro.