У меня есть VPS-сервер Ubuntu (9.04 / Jaunty), который неправильно меняет системные журналы.
Вот что я пока что проверил:
test -x /usr/sbin/syslogd-listfiles
, test -x /sbin/syslogd
, test -f /usr/share/sysklogd/dummy
)sudo run-parts --verbose /etc/cron.daily
) журналы вращаются, как я ожидалУ кого-нибудь есть идеи, что я могу попробовать дальше или чего мне может не хватать? Я думал, что, возможно, тот факт, что sysklogd, кажется, запускает свой процесс как syslog (владелец syslogd на ps -C syslogd -o user= | head -n 1
) означает, что есть какая-то проблема с разрешениями, и, похоже, это подтверждается результатами запуска sudo -u syslog run-parts --verbose /etc/cron.daily
что заканчивается кучей ошибок разрешений, но я не уверен, как лучше всего решить эту проблему.
Ниже приведено содержимое моего файла sysklogd, на случай, если это поможет. В touch /etc/crontouchtest
bit - это то, что я вставил, чтобы проверить успешное выполнение файла. Он обновляет время последнего использования (ls -lut /etc/crontouchtest
), когда я выполняю run-parts как root, но не при запуске cron.daily.
#! /bin/sh
# sysklogd Cron script to rotate system log files daily.
#
# If you want to rotate other logfiles daily, edit
# this script. An easy way is to add files manually,
# to add -a (for all log files) to syslogd-listfiles and
# add some grep stuff, or use the -s pattern argument to
# specify files that must not be listed.
#
# This is a configration file. You are invited to edit
# it and maintain it on your own. You'll have to do
# that if you don't like the default policy
# wrt. rotating logfiles (i.e. with large logfiles
# weekly and daily rotation may interfere). If you edit
# this file and don't let dpkg upgrade it, you have full
# control over it. Please read the manpage to
# syslogd-listfiles.
#
# Written by Martin Schulze <joey@debian.org>.
# $Id: cron.daily,v 1.14 2007-05-28 16:33:34 joey Exp $
test -x /usr/sbin/syslogd-listfiles || exit 0
test -x /sbin/syslogd || exit 0
test -f /usr/share/sysklogd/dummy || exit 0
touch /etc/crontouchtest
USER=$(ps -C syslogd -o user= | head -n 1)
[ -z "${USER}" ] && USER="root" || true
set -e
cd /var/log
logs=$(syslogd-listfiles)
test -n "$logs" || exit 0
for LOG in $logs
do
if [ -s $LOG ]; then
savelog -g adm -m 640 -u ${USER} -c 7 $LOG >/dev/null
fi
done
# Restart syslogd
#
/etc/init.d/sysklogd reload-or-restart > /dev/null
РЕДАКТИРОВАТЬ
Результаты по запросу:
ls -la /etc/cron.daily (run as root)
drwxr-xr-x 2 root root 4096 Oct 23 07:13 .
drwxr-xr-x 107 root root 4096 Oct 23 07:14 ..
-rwxr-xr-x 1 root root 314 Feb 10 2009 aptitude
-rwxr-xr-x 1 root root 111 May 11 11:49 backup-manager
-rwxr-xr-x 1 root root 89 Jan 26 2009 logrotate
-rwxr-xr-x 1 root root 1334 Oct 22 09:35 sysklogd
ps -ef | egrep '[c]ron' (run as root)
root 13369 1 0 Oct21 ? 00:00:02 /usr/sbin/cron
РЕДАКТИРОВАТЬ 2
Соответствующие пути
из echo $PATH
(после перехода в root):
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
из /etc/crontab
:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Бит touch / etc / crontouchtest - это то, что я вставил, чтобы проверить, успешно ли выполняется файл. Он обновляет время последнего использования (ls -lut / etc / crontouchtest), когда я выполняю run-parts от имени root, но не при запуске cron.daily.
Если я правильно прочитал, /etc/crontouchtest
не обновляется, когда cron
запускает задачи cron.daily. Это вкупе с тем, что /etc/cron.daily/sysklogd
работает правильно при запуске вручную, заставляет меня подозревать, что что-то вызывает run-parts
не запустить /etc/cron.daily/sysklogd
когда run-parts
управляется cron
.
поскольку cron
выполняется как root, и ваш ручной тест также запускался как root, разница между двумя средами очень небольшая. Все, о чем я могу думать, это то, что cron
возможно, запускается с другим PATH по сравнению с PATH, который существует в командной строке. Кроме того, когда процесс запускается cron
, нет управляющего терминала. Может ли какое-либо из этих различий объяснить разницу в результатах?
Отвечаю на этот вопрос, чтобы было легче найти решение.
Задание sysklogd cron по умолчанию сначала проверяет наличие анакрона, и при его обнаружении не запускает ротацию журналов для системных журналов. Как предположил @Steven, я удалил анакрон из системы (поскольку это сервер и предназначен для работы 24/7/365, функции анакрона на самом деле не нужны). После того, как anacron был отключен от системы, тест anacron в задании cron завершился ошибкой, и ротация системного журнала работала как чемпион.
Спасибо @ Стивен