Bem, estou supondo que os projetistas do logcheck decidiram que esse cenário é um erro de configuração que vale a pena reclamar, mas não é um erro de operação. Nesse cenário, o logcheck ainda pode ser executado e ainda opera em /var/log/rsyncd.log. Ignorar um segundo arquivo de configuração não impede que o logcheck continue, portanto, o status relatado é 0.
Especialmente no software para servidores, presume-se que você tenha verificado seus arquivos de configuração antes de implantá-los. Embora a vantagem aqui seja um alerta mais óbvio para a questão, a desvantagem seria a preocupação com quaisquer tarefas que dependam do logcheck.
Tudo isso dito, você não pode confiar no estado ao passar -d para ser o mesmo que na operação normal. Citando man logcheck : No modo de depuração, nenhuma alteração será feita nos logs ou no arquivo de estado logrotate. . Assim, a operação de ler as coisas e relatá-las com detalhes foi bem-sucedida e deve retornar 0. Isso pode não estar relacionado ao que você obtém com o modo de depuração desativado.
Em qualquer caso, no final, isso pode ser mais um debate de design de software do que qualquer outra coisa. Como um sysadmin, a verificação dos arquivos de configuração na produção deve ser feita como sua própria tarefa.
Compare tudo isso com um jargão inaudível no arquivo de configuração que certamente lhe dará um código diferente de zero em qualquer software decente.