Выходные данные rsync (текущие) не записываются в новый файл журнала после ротации с помощью newsyslog
Сегодня утром я обнаружил, что текущие выходные данные rsync не появляются в журнале rsync после ротации с помощью newsyslog. Он потерян
Другими словами,
- запущенный rsync ведет журнал в /var/log/rsync
- newsyslog делает ротацию журналов
- в новом /var/log/rsync не появляется никакого вывода.
- Вывод нигде не фиксируется.
Что я делаю не так?
Вот команда rsync (извлекается из модуля rsyncd в окне Windows, на котором запущен cygwin). Это часть команды rsnapshot, но она не имеет отношения к данной проблеме.
/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/
Вот последние 5 строк файла /var/log/rsync.0 (после распаковки).
[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
Вот что находится в /var/log/rsync:
> [root@offsite1 ~]# tail -5 /var/log/rsync Feb 11 01:00:00 offsite1
> newsyslog[61988]: logfile turned over
Вот несколько последних строк того, что было на моем экране, когда я отключил задание rsync сегодня утром (я оставил команду tail -f /var/log/ rsync работает всю ночь). Это должно отображаться в /var/log/rsync, так как я запускал на нем хвост -f. У меня есть опыт такого типа вывода, появляющегося в /var/log/rsync, когда newsyslog не задействован.
> 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]
Вот что находится в /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
и, наконец,
[root@offsite1 ~]# uname -a
FreeBSD offsite1.domanname.com 12.0-RELEASE-p3 FreeBSD 12.0-RELEASE-p3 GENERIC amd64
newsyslogпереместит файл журнала на новое имя(/var/log/rsync.0)и сожмет его (до /var/log/rsync.0.bz2из-за флага J, который вы используете вnewsyslog.conf). Затем он создает новый файл со старым именем (и флагом Cв newsyslog.conf).
Это означает, что процесс (es )записывающий в этот файл будет записывать в файл, которого больше не существует (ну, он существует, но без имени ).Индексный дескриптор, соответствующий /var/log/rsync, больше не будет иметь имени, а пространство, используемое файлом, будет освобождено после того, как rsyncзакроет дескриптор файла. Инод потерял свое имя, когда файл был сжат.
Обычно системные службы отправляют сигнал HUPчерез newsyslog, и обычно это означает, что они повторно открывают свои файлы журналов для записи. Это означает, что они начнут писать в только что очищенный лог-файл, а не в пустоту.
rsyncне имеет такой возможности, насколько мне известно, поэтому все, что будет записано после точки, в которой происходит ротация лог-файла, будет потеряно.
В зависимости от того, как создается резервная копия rsync.0файла, вы можете rsyncпродолжить запись в этот файл, если просто отключите сжатие ротированных журналов.
Это можно сделать с помощью флага pв столбце флагов newsyslog.conf, который оставит нулевой ротируемый файл журнала несжатым, но сожмет старые файлы. См. newsyslog.conf(8).
Обратите внимание, что отключение сжатия только первого журнала по-прежнему будет вызывать проблемы, если один и тот же процесс rsyncостанется активным в течение второго чередования файлов журнала, поскольку файл rsync.0будет переименован в rsync.1. ], а затем сжимается доrsync.1.bz2(и снова та же проблема ). Полное отключение сжатия файла журнала поможет решить эту проблему.