Копытов Иван: заметки с тегом syslogd

Syslog. Продолжаем наблюдение

Tue, 03 Oct 2017 17:43:19 +0700

Наблюдение показало, что «валится» syslogd в очень определенное время — в момент окончания работы logrotate. Пройдя через цепочку файлов, наткнулся на упоминание reload-syslog в папке /sbin. Полез посмотреть что это за файл, а он представляет собой обычный скрипт, в котором есть такая строчка:

/sbin/service $n reload && break

Мелькнула «шальная» мысль, которая заставила меня заменить reload на restart. Следом я удалил скрипт, который перезапускал syslogd через 1 час, после того, как он «вешался». День первый — полет нормальный. Продолжаем наблюдение...

Продолжаем наблюдение за syslog

Mon, 02 Oct 2017 00:05:32 +0700

Как писал ранее на сервере наблюдаются проблемы с syslog. Этот паршивец каждую ночь перестает писать журналы. Причины пока непонятны, надо будет задать вопрос разработчикам системы. В качестве временной меры выбран перезапуск службы в планировщике cron. Этого, по идее, должно быть достаточно. По крайней мере, пока что. Дальше будем разбираться. Ситуацию усложняет момент, что время в журналах записывается на тот момент, когда была перезапущена служба, а не то, когда что-то произошло. Иными словами, я не могу отследить кто или что «подвешивает» её. Но, с учетом вероятного времени «подвисания» syslogd, можно предположить, что это происходит после выполнения заданий в /etc/cron.daily. То есть, можно по одному удалять оттуда файлы и наблюдать после чего служба перестанет «вешаться».
Если выполнить команду

service syslogd status

то система ответит «active». Но запись журналов начнется после перезапуска syslog. В общем, пока что «продолжаем наблюдение» и экспериментируем.

Проблемы с журналами в linux

Tue, 26 Sep 2017 18:31:33 +0700

Давненько уже заметил, что перестали писаться некоторые журналы. Если быть точней, то, наверное, большинство. Поэтому правильней было бы сказать, что писались только некоторые. Потихоньку экспериментировал с journalctl, но результатов это не приносило. Да и другой работы было столько, что времени особо и не хватало. Сегодня в очередной раз вспомнил об этой проблеме, решил покопаться, пока рабочий день потихоньку подходил к концу — я ожидал окончания проверки диска.
В какой-то момент в голове мелькнула мысль, что виной всему, скорее всего, настройки syslogd. Но файл конфигурации я до этого просматривал, криминала никакого не заметил. Впрочем, моих познаний в linux могло и не хватить. Поэтому решил снести syslogd, почистить конфиги и запустить его заново. Для этого хватило одного команды:

apt-get install --purge --reinstall syslogd syslog-common

Проверяем статус службы, перезапускаем на всякий случай еще раз, идем смотреть логи почты — они более важны, чем другие. Файл all изменил свой размер, перестал быть «нулевым». Пробуем отправить самому себе письмо, запустив перед этим команду

tail -f /var/log/mail/all

И, о счастье, весь ход работы почты отображается, как и следует. Смотрим остальные логи — вроде все пишется. Пока что понаблюдаю еще, возможно, что некоторые все-таки будут «сопротивляться», хотя и маловероятно.