Início / unix / Perguntas / 500014
Accepted
BISI
Asked: 2019-02-12 11:09:41 +0800 CST

saída rsync (em andamento) não registrada no novo arquivo de log após rotação com newsyslog

  • 772

Descobri esta manhã que a saída rsync em andamento não aparece no log rsync após a rotação por newsyslog. está perdido

Em outras palavras,

  • um rsync em execução está registrando em /var/log/rsync
  • newsyslog faz a rotação de log
  • nenhuma saída aparece no novo /var/log/rsync.
  • A saída não é capturada em nenhum lugar que eu possa ver.

O que estou fazendo errado?

Aqui está o comando rsync (extrai de um módulo rsyncd em uma caixa do Windows executando o cygwin). Faz parte de um comando rsnapshot, mas isso não é relevante para esse problema.

/usr/local/bin/rsync -av --delete --relative --delete-excluded --stats --log-file=/var/log/rsync --human-readable --no-owner --no-group --exclude-from=/yada/yada/.rsnapshot_excludes 192.168.3.130::INC-10890_data/ /zfspoolname/archives/daily.0/LOCATIONSIGNIFIER/INC-10890_data/

Aqui estão as últimas 5 linhas de /var/log/rsync.0 (após descompactar).

[root@offsite1 ~]# tail -5 /var/log/rsync.0
2019/02/11 01:03:54 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_102.bmp
2019/02/11 01:03:55 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_103.bmp
2019/02/11 01:03:55 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_104.bmp
2019/02/11 01:03:55 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_105.bmp
2019/02/11 01:03:55 [20023] >f+++++++++ master/20170801/000054420170801010001/000054420170801010001oct_c_106.bmp

Aqui está o que está em /var/log/rsync:

> [root@offsite1 ~]# tail -5 /var/log/rsync   Feb 11 01:00:00 offsite1
> newsyslog[61988]: logfile turned over

Aqui estão as últimas linhas do que estava na minha tela quando eu matei o trabalho rsync esta manhã (deixei o comando tail -f /var/log/rsync rodando durante a noite). Isso deve aparecer em /var/log/rsync, já que eu estava executando um tail -f nele. Eu tenho experiência desse tipo de saída que aparece em /var/log/rsync quando o newsyslog não está envolvido.

> 2019/02/11 07:13:52 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_027.bmp
> 2019/02/11 07:13:52 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_028.bmp
> 2019/02/11 07:13:53 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_029.bmp
> 2019/02/11 07:13:53 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_030.bmp
> 2019/02/11 07:13:53 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_031.bmp
> 2019/02/11 07:13:53 [20023] >f+++++++++
> master/20170914/000504720170914030001/000504720170914030001oct_c_032.bmp
> 2019/02/11 07:13:54 [12868] rsync error: received SIGINT, SIGTERM, or
> SIGHUP (code 20) at rsync.c(689) [generator=3.1.3] 2019/02/11 07:13:54
> [20023] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at
> io.c(504) [receiver=3.1.3]

Aqui está o que está em /usr/local/etc/newsyslog.conf.d/rsync

#
# The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'.
#
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/rsync                          644  13    *    $W1D01 JCN

e finalmente

[root@offsite1 ~]# uname -a
FreeBSD offsite1.domanname.com 12.0-RELEASE-p3 FreeBSD 12.0-RELEASE-p3 GENERIC  amd64
rsync freebsd

1 respostas

  1. Best Answer

    newsyslogirá mover o arquivo de log para um novo nome ( /var/log/rsync.0) e comprimi-lo (para /var/log/rsync.0.bz2, devido ao Jsinalizador que você usa em newsyslog.conf). Em seguida, ele cria um novo arquivo com o nome antigo (o Csinalizador em newsyslog.conf).

    Isso significa que o(s) processo(s) gravando nesse arquivo gravará em um arquivo que não existe mais (bem, existe, mas sem nome). O inode ao qual correspondia /var/log/rsyncnão terá mais nome e o espaço utilizado pelo arquivo será recuperado assim que o arquivo for rsyncfechado. O inode perdeu seu nome quando o arquivo foi compactado.

    Normalmente, os serviços do sistema recebem o HUPsinal newsysloge geralmente isso significa que eles reabrirão seus arquivos de log para gravação. Isso significa que eles começarão a gravar no arquivo de log recém-limpo e não no void.

    rsyncnão tem essa facilidade até onde eu sei, então tudo o que é escrito após o ponto em que o arquivo de log é girado será perdido.

    Dependendo de como o arquivo de backup rsync.0é criado, você pode rsynccontinuar gravando nesse arquivo se simplesmente desabilitar a compactação dos logs girados.

    Você pode fazer isso usando o psinalizador na coluna sinalizador de newsyslog.conf, que deixará o arquivo de log girado zero descompactado, mas compactará os mais antigos. Veja newsyslog.conf(8).

    Observe que desabilitar a compactação do primeiro log ainda causaria problemas se o mesmo rsyncprocesso permanecesse ativo durante a segunda rotação do arquivo de log, pois o rsync.0arquivo seria renomeado rsync.1e compactado rsync.1.bz2(é o mesmo problema novamente). Desabilitar completamente a compactação do arquivo de log resolveria isso.

    • 2

relate perguntas