Rotating logs gerados a partir do tcpdump com logrotate

Question

Em uma caixa linux de produção, estou capturando pacotes SIP usando a seguinte configuração:

logrotate.conf:

# Opensips SIP traces 
/var/log/sip.log
{
        rotate 31
        daily
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                pkill tcpdump
                /home/ubuntu/log-sip-messages.sh &
        endscript
}

log-sip-messages.sh:

#!/bin/sh
tcpdump host 159.63.X.X -s0 -v >> /var/log/sip-159.63.X.X.log

Isso funciona muito bem no servidor Ubuntu 11.04, mas nas caixas do Ubuntu 12.10, isso apenas produz um arquivo com um timestamp no momento em que os logs foram rotacionados. É como se o pkill não completasse antes de executar o tcpdump novamente para começar a escrever no novo arquivo.

Eu tentei executar isso diretamente do terminal como um experimento:

pkill tcpdump && tcpdump -s0 -v udp >> /var/log/sip.log

e quando eu executo ps aux|grep tcpdump não há nenhum processo em execução, confirmando o que eu já sei ... o comando pkill é executado de forma assíncrona em 12.10 (mas é síncrono em 11.04 ou apenas bate o segundo comando)

Como posso fazer isso funcionar para que eu possa capturar o tráfego de rede em um arquivo de log legível e agradável (não preciso de pcaps) sem arriscar o preenchimento de meu espaço no disco rígido?

    

Answer 1

Tudo isso me inspirou a entrar na página do logrotate para ver que tipo de ferramentas estão à minha disposição. Descobri que copytruncate faz uma cópia do arquivo de log e, em seguida, o trunca, mas sem interromper o processo que grava nele. Meu teste mostra que ele gira os logs e permite que o tcpdump continue gravando no arquivo limpo. Eu deixei um cronjob de hora em hora rodando durante a noite usando um arquivo de configuração de teste, então eu rodaria esses logs a cada hora. Funcionou:

# Opensips SIP traces 
/var/log/sip.log
{
        rotate 31
        daily
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        copytruncate
}

Uma possível desvantagem é que, se o processo tcpdump for eliminado por alguém que não saiba o que estou fazendo, precisarei entrar e reiniciar o processo manualmente, mas isso é suficiente por enquanto.

O outro problema potencial é que, se o arquivo de log é muito grande, fazer uma cópia pode exigir muito espaço em disco, para o qual eu tenho muito no momento, mas o processo pode ser interrompido se não houver espaço suficiente para fazer uma cópia.

    

Answer 2

A entrega do sinal Unix é assíncrona. Quando a chamada do sistema kill retornar, o sinal foi entregue ao processo, mas o processo pode não ter reagido a ele ainda. Você teve sorte com o agendador em 11.04. Se o processo eliminado tiver um manipulador para o sinal, ele poderá gastar um tempo arbitrariamente longo antes de morrer ou optar por não morrer como resultado do sinal.

Você pode usar um bloqueio para garantir que a nova instância do processo não comece até que a anterior termine.

Além disso, eu não recomendo indiscriminadamente matar tcpdump processos: e se houver outras instâncias em execução? Em vez disso, mate qualquer processo que tenha o arquivo de bloqueio aberto.

#!/bin/sh
lockfile=/var/run/log-sip-messages.lock
# Kill all processes that have the lock file open
fuser -k -TERM "$lockfile" >/dev/null 2>/dev/null
(
  # Wait until the lock is released
  flock -s 3
  # Don't let this shell be killed by fuser: wait until tcpdump exits
  trap : TERM
  # Call tcpdump with the lock file open, so that fuser kills it
  tcpdump -s0 -v udp >> /var/log/sip.log
) 3>"$lockfile"

E do logrotate, execute somente /home/ubuntu/log-sip-messages.sh .

    

Answer 3

Uma ideia seria introduzir algum tempo de espera entre o pkill e o início do backup de tcpdump ( /home/ubuntu/log-sip-messages.sh & ). Isso parece um hack, e é, mas algo assim:

    postrotate
            pkill tcpdump
            sleep 3
            /home/ubuntu/log-sip-messages.sh &
    endscript