Ordem de syslog estranha

Você já viu uma ordem errada em / var / log / syslog? Eu acho que isso causa apenas crontab.

Jun 28 22:20:01 alex CRON[2327]: (root) CMD (something > /dev/null)
Jun 28 22:21:01 alex CRON[2700]: (root) CMD (something > /dev/null)
Jun 21 03:49:01 alex CRON[2753]: (root) CMD (something > /dev/null)
Jun 28 22:23:01 alex CRON[2754]: (root) CMD (something > /dev/null)
Jun 27 05:08:01 alex CRON[2813]: (root) CMD (something > /dev/null)
Jun 26 00:19:01 alex CRON[2816]: (root) CMD (something > /dev/null)
Jun 28 22:25:01 alex CRON[2816]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
Jun 28 22:25:01 alex CRON[2821]: (root) CMD (something > /dev/null)
Jun 28 22:27:01 alex CRON[3225]: (root) CMD (something > /dev/null)
Jun 28 22:28:01 alex CRON[3240]: (root) CMD (something > /dev/null)
Jun 28 22:30:01 alex CRON[3290]: (root) CMD (something > /dev/null)
Jun 26 12:03:01 alex CRON[3291]: message repeated 2 times: [ (root) CMD (something > /dev/null)]
Jun 28 22:30:01 alex CRON[3291]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
Jun 28 22:31:01 alex CRON[3659]: (root) CMD (something > /dev/null)
Jun 28 22:32:01 alex CRON[3754]: (root) CMD (something > /dev/null)
Jun 16 06:41:01 alex CRON[3846]: (root) CMD (something > /dev/null)
Jun 28 22:35:58 alex cron[909]: (CRON) INFO (pidfile fd = 3)
Jun 28 22:35:58 alex cron[944]: (CRON) STARTUP (fork ok)
Jun 28 22:35:58 alex cron[944]: (CRON) INFO (Running @reboot jobs)
Jun 28 22:36:01 alex CRON[1428]: (root) CMD (something > /dev/null)
Jun 28 22:37:01 alex CRON[3050]: (root) CMD (something > /dev/null)
Jun 28 22:38:01 alex CRON[3082]: (root) CMD (something > /dev/null)
Jun 28 22:39:01 alex CRON[3114]: (root) CMD (something > /dev/null)

Como você pode ver, há uma ordem de tempo ruim entre as linhas. É apenas erro crontab, ou há algum problema com o relógio do sistema, ou algo assim?

Estou executando o kernel mais recente do Ubuntu 14.04:

Linux alex 3.13.0-30-generic #54-Ubuntu SMP Mon Jun 9 22:45:01 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

— Tomasz
fonte

O pedido está realmente errado ou apenas os registros de data e hora? No primeiro caso, o syslog deve ser responsável, caso contrário, cron ou seu relógio.

— wonce 29/06

Parece que os outros logs, exceto cron, estão OK. Eu adicionei o tempo de log pelo script "something", não apenas pelo cron e pelo syslog.

— Tomasz

Isso aconteceu em uma caixa que rodava o fedora, e o rsyslog caiu, mas o journald manteve os logs que foram encaminhados ao rsyslog assim que ele começou, resultando em mensagens antigas misturadas com as novas. Isso foi no fedora 20.

— Petter H

Eu encontrei o mesmo problema no Ubuntu 14.04. Cerca de 1 em cada 20 mensagens cron tem uma data de 5 a 7 dias no passado. Somente com mensagens cron e o problema persiste após uma reinicialização.

— Jasper Krijgsman

Posso confirmar esse problema, o Ubuntu 14.04, acontece com as mensagens cron.

— thor

Respostas:

Este é um assunto complicado e, na verdade, é um bug no rsyslog, especificamente RepeatedMsgReduction On, e uma mudança de comportamento com a versão lançada com o Trusty (comparada às versões anteriores)

Veja http://bugzilla.adiscon.com/show_bug.cgi?id=527 para obter os detalhes sangrentos.

Em resumo, desative RepeatedMsgReduction em Trusty (por exemplo sudo sed -i -r 's/^\$RepeatedMsgReduction.*/$RepeatedMsgReduction off/' /etc/rsyslog.conf). Não é útil e faz coisas idiotas.

— Craig Miskell
fonte

Por favor, não poste exatamente a mesma resposta duas vezes. Use comentários para se referir à sua primeira resposta. A melhor opção é votar em fechar como duplicado.

— Sven

A ironia ... parece que você pode querer RepeatedMsgReduction ativado! : D

— Anonymous Penguin

O que faz você dizer isso, Anonymous Penguin?

— Craig Miskell

Parece que a versão 7.4.4-1ubuntu2.7 do pacote rsyslog corrige esse problema: changelogs.ubuntu.com/changelogs/pool/main/r/rsyslog/…

— Mauro Molinari

Talvez sua máquina tenha reiniciado por volta de então? Com base no seu log, parece que o cron foi reiniciado pelo menos. É possível que você tenha uma bateria CMOS com defeito e sua máquina não esteja mantendo o tempo exato quando desligada.

Esta é uma máquina virtual? Talvez tenha sido migrado para um host diferente e o relógio tenha ficado incorreto durante a migração?

Seu script 'algo' talvez acerte o horário por acidente?

Realmente, isso pode ser qualquer número de coisas. Esse não é um comportamento normal.

— devicenull
fonte

parece apenas um problema de syslog, porque eu fiz o login independente direto para executar o script e parece bom, sem espaços ou ordem mista.

— Tomasz