Со временем заметил несколько логов в /var/log Такие как auth, kern и messages становились огромными. я сделал logrotate записи для них:
$ cat /etc/logrotate.d/auth.log
/var/log/kern.log {
rotate 5
daily
}
$ cat /etc/logrotate.d/kern.log
/var/log/kern.log {
rotate 5
daily
}
$ cat /etc/logrotate.d/messages
/var/log/messages {
rotate 5
daily
postrotate
/bin/killall -HUP syslogd
endscript
}
также у меня есть compress опция включена:
$ grep compress /etc/logrotate.conf
# uncomment this if you want your log files compressed
compress
Это отлично работает для auth.log, kern.log и другие, что означает, что каждый из этих журналов архивируется и вращается с сохранением журналов за последние 5 дней. /var/log/messages однако это не сжимаются, в результате чего журналы хранятся более 5 дней:
$ ls /var/log/messages*
/var/log/messages /var/log/messages-20100213
/var/log/messages-20100201 /var/log/messages-20100214
/var/log/messages-20100202 /var/log/messages-20100215
/var/log/messages-20100203 /var/log/messages-20100216
/var/log/messages-20100204 /var/log/messages-20100217
/var/log/messages-20100205 /var/log/messages-20100218
/var/log/messages-20100206 /var/log/messages-20100219
/var/log/messages-20100207 /var/log/messages-20100220
/var/log/messages-20100208 /var/log/messages-20100221
/var/log/messages-20100209 /var/log/messages-20100222
/var/log/messages-20100210 /var/log/messages-20100223
/var/log/messages-20100211 /var/log/messages-20100224
/var/log/messages-20100212
Как объясняется в другой logrotate вопрос по ServerFault, старые журналы (скорее всего) не удаляются, потому что окончания файлов различны для каждого файла. Похоже, это связано с тем, что файлы не архивируются.
Что я могу сделать, чтобы иметь /var/log/messages сжаты и повернуты с сохранением журналов за последние 5 дней, как и все другие мои файлы журналов? Что мне не хватает?
ИЗМЕНИТЬ 1: дополнительная информация, запрошенная в первой паре ответов.
Я использую Gentoo Linux. Мой /etc/logrotate.conf файл:
$ cat /etc/logrotate.conf
# $Header: /var/cvsroot/gentoo-x86/app-admin/logrotate/files/logrotate.conf,v 1.3 2008/12/24 20:49:10 dang Exp $
#
# Logrotate default configuration file for Gentoo Linux
#
# See "man logrotate" for details
# rotate log files weekly
weekly
#daily
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# use date as a suffix of the rotated file
dateext
# uncomment this if you want your log files compressed
compress
# packages can drop log rotation information into this directory
include /etc/logrotate.d
notifempty
nomail
noolddir
# no packages own lastlog or wtmp -- we'll rotate them here
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0600 root utmp
rotate 1
}
/etc/logrotate.d содержит мои пользовательские файлы конфигурации, как указано выше, а также конфигурации для mysql, rsync и т.д., установленные этими пакетами.
Мой корень crontab пусто:
$ sudo crontab -l
no crontab for root
Я проверил все /etc/cron.{daily,hourly,monthly,weekly} для всего, что связано с системным журналом, и есть сценарий, который вращает /var/log/syslog и /var/log/auth.log.
Затем я сделал /var/log/messages-только logrotate config, предложенный CarpeNoctem:
$ cat logrotate-messages
weekly
rotate 4
create
dateext
compress
notifempty
nomail
noolddir
/var/log/messages {
rotate 5
daily
postrotate
/bin/killall -HUP syslogd
endscript
}
Затем я побежал logrotate вручную:
$ logrotate -d logrotate-messages -f
reading config file logrotate-messages
reading config info for /var/log/messages
Handling 1 logs
rotating pattern: /var/log/messages forced from command line (5 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/messages
log needs rotating
rotating log /var/log/messages, log->rotateCount is 5
dateext suffix '-20100224'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
glob finding old rotated logs failed
renaming /var/log/messages to /var/log/messages-20100224
creating new /var/log/messages mode = 0644 uid = 0 gid = 0
running postrotate script
running script with arg /var/log/messages : "
/bin/killall -HUP syslogd
"
compressing log with: /bin/gzip
$ which gzip
/bin/gzip
$ file /bin/gzip
/bin/gzip: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
Согласно журналу выше, logrotate сжал журнал с помощью / bin / gzip, но я не вижу файла сжатых сообщений в /var/log. Кроме того, не удалось найти старые повернутые файлы.
РЕДАКТИРОВАТЬ 2: добавление отладочного вывода logrotate запустить после добавления .gz суффикс к старому /var/log/message-* файлы.
Начнем с:
$ ls /var/log/messages*
/var/log/messages /var/log/messages-20100222.gz
/var/log/messages-20100219.gz /var/log/messages-20100223.gz
/var/log/messages-20100220.gz /var/log/messages-20100224.gz
/var/log/messages-20100221.gz
Тогда беги logrotate с нашим настраиваемым файлом конфигурации:
$ logrotate -d logrotate-messages -f
reading config file logrotate-messages
reading config info for /var/log/messages
Handling 1 logs
rotating pattern: /var/log/messages forced from command line (5 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/messages
log needs rotating
rotating log /var/log/messages, log->rotateCount is 5
dateext suffix '-20100224'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
removing /var/log/messages-20100219.gz
removing old log /var/log/messages-20100219.gz
destination /var/log/messages-20100224.gz already exists, skipping rotation
В это время, logrotateКоманда glob завершается успешно и находит шестой сжатый файл журнала, намереваясь удалить его. На самом деле файл не удаляется; Я думаю, это потому, что мы работаем в режиме отладки.
Мне любопытно, включить ли delaycompress вариант для /var/log/messages поможет. Я включил его и на следующее утро проверю результаты.
Добавление delaycompress в раздел конфигурации для /var/log/messages решил проблему.
Из man logrotate:
delaycompress
Postpone compression of the previous log file to the next rota‐
tion cycle. This only has effect when used in combination with
compress. It can be used when some program cannot be told to
close its logfile and thus might continue writing to the previ‐
ous log file for some time.
я думаю sysklogdМоему демону системного журнала нельзя приказать закрыть файл журнала, поэтому это необходимо.
Интересно, что исходная конфигурация у меня была (без delaycompress директива), пришла прямо из man logrotate (за исключением того, что я изменил weekly к daily):
# sample logrotate configuration file
compress
/var/log/messages {
rotate 5
weekly
postrotate
/usr/bin/killall -HUP syslogd
endscript
}
Сложно сказать с помощью этой информации, но я могу сказать вам, что меня спасало несколько раз.
В Logrotate есть опция отладки, которая распечатывает пошаговую инструкцию для каждого шага, который требуется для вывода на стандартный вывод. Итак, в этом случае вы можете:
logrotate -d /etc/logrotate.conf
Вывод сообщит вам, что именно происходит. Кроме того, если вы хотите сузить вывод отладки, вы можете сделать
logrotate -d /etc/logrotate.d/messages
Хотя вы можете временно разместить основные параметры logrotate.conf в этом блоке файлов, поскольку указание файла напрямую означает, что он никогда не будет читать основные параметры конфигурации. Указание отдельного файла также означает, что вы можете использовать -f (принудительно) в сочетании с параметром отладки, чтобы увидеть, как происходит ротация файла сообщений.
Попробуйте использовать этот параметр в своем logrotate.conf:
dateformat .%Y%m%d
и переименуйте существующие файлы сообщений, чтобы использовать точку вместо тире. Затем попробуйте снова выполнить логротейт.
Приведенные ниже подсказки заставили меня поверить, что тире может привести к сбою глобуса, если он каким-то образом интерпретируется как опция (где - исправит это). Это не имеет смысла, но вполне возможно.
dateext suffix '-20100224'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
glob finding old rotated logs failed