Obviously if the system runs for days I might no get this information. Is my understanding correct here?
Sim. Depende de quanta informação de log é gerada, mas eventualmente a informação de inicialização irá rolar para fora do começo do buffer de anel do kernel e do diário do systemd. Não é um guia sobre quanto tempo leva em sistemas de outra pessoa, mas eu tenho sistemas que têm uptimes nas centenas de dias cujos dados de log de inicialização há muito tempo rolaram para fora da parte superior do diário do systemd. Essa é uma das desvantagens de ter um fluxo de logs combinado gigante no qual tudo aconteça e os fãs voltem novamente.
Então pegue uma folha do FreeBSD e do NetBSD e seus derivados. Todos eles possuem serviços que são executados uma vez, no bootstrap logo após os sistemas de arquivos locais terem sido montados, o que simplesmente faz:
dmesg > /var/run/dmesg.boot
Assim, uma captura instantânea do log do kernel, como estava no bootstrap, está disponível em /var/run/dmesg.boot , mesmo que tenha sido rolada dos logs reais.
Você simplesmente precisa escrever um serviço systemd que faça o mesmo. Use o shell para redirecionamento,
ExecStart=/bin/sh -c "exec dmesg > /run/dmesg.boot"ou use algo como
redirfd de Laurent Bercot ou o conjunto de ferramentas do nosh fdredir ExecStart=/usr/local/bin/fdredir --write 1 /run/dmesg.boot dmesg
Substitua journalctl -k se você quiser tirar uma foto instantânea do diário do systemd em vez de apenas o log do kernel, e faça disso um Type=oneshot service. Deseja obter multi-user.target ou torná-lo um DefaultDependencies=no de serviço desejado por basic.target . Observe que ele não precisa ser pedido após montagens de sistema de arquivos locais (por exemplo, local-fs.target ). Essa ordenação é necessária para o FreeBSD e OpenBSD porque /var/run poderia ser um sistema de arquivos em disco com eles. Em sistemas operacionais systemd /run é um "sistema de arquivos API" criado na inicialização antes de qualquer serviço.
(A abordagem que eu pessoalmente prefiro é não ter o fluxo de logs central gigante em primeiro lugar. Um serviço dedicado se alimenta do feed de log do kernel sozinho e registra em um diretório de log privado. leva muito mais tempo para chegar ao ponto em que as últimas informações de inicialização rola para fora do topo e também contém logs de inicialização de inicializações anteriores.
No entanto, isso é muito mais complexo para configurar em um mundo systemd do que um oneshot que grava um /run/dmesg.boot . É simples no mundo da família daemontools, no entanto. É um exercício trivial no uso de ferramentas como fifo-listen e klog-read ou socklog . Pipetar a saída através de um servidor de logs que grava em um diretório privado, rotacionado automaticamente e com rotação automática, é fornecido como padrão com um serviço gerenciado daemontools / runit / s6 / nosh / perp.)