Na verdade, essa ideia está muito errada. Em primeiro lugar, esta mensagem não representa necessariamente um único bloco de 18 mensagens systemd sucessivas que foram perdidas. Em segundo lugar, você não pode dizer quando o / dev / kmsg foi validado se o processo ainda está aberto para gravação. Você só recebe uma mensagem quando o processo fecha / dev / kmsg. A mensagem mostra uma contagem de todas as linhas suprimidas desse gravador.
Cada gravador individual (descritor de arquivo) para /dev/kmsg obtém sua própria estrutura ratelimit. E como parte da inicialização ...
ratelimit_set_flags(&user->rs, RATELIMIT_MSG_ON_RELEASE);
a ratelimit está configurada para fazer logon apenas na versão. Ou seja, quando o descritor de arquivo está fechado. Para um processo de longa duração, isso pode ser menos do que útil ... e o sistema init, ou seja, o systemd definitivamente conta como um processo de longa execução.
O motivo pelo qual você vê esta mensagem de log, é que systemd do initrd fecha / dev / kmsg antes que exec() s systemd do sistema de arquivos raiz do sistema.
Assim, as mensagens perdidas durante o initrd não são necessariamente perdidas como um bloco. Poderia haver vários blocos diferentes de mensagens perdidas, portanto, o registro não seria tão simples de analisar quanto eu pensava.
Além disso, qualquer número de mensagens poderia ter sido perdido mais tarde, do tempo entre exec() ing systemd do sistema de arquivos raiz, até o ponto em que o systemd para completamente o / dev / kmsg e alterna para journald . E de fato eles são, o que podemos ver durante o desligamento (usando um console que permanece ligado, como um console serial). Quando systemd exec() s systemd-shutdown, / dev / kmsg é automaticamente fechado, e nós vemos
[ OK ] Reached target Final Step.
Starting Reboot...
[ 76.318839] systemd-shutdow: 32 output lines suppressed due to ratelimiting
...
Tudo isso está em contraste com certas mensagens limitadas do kernel, por exemplo. %código%. Neste caso, o RATELIMIT_MSG_ON_RELEASE não é usado.