Указывает ли этот журнал перезагрузку сервера?
У меня есть веб-сервер, который, я думаю, в какой-то момент перезагружается... в основном потому, что apache не обслуживает сайты и обычно делает это, когда кто-то запускает его и не вводит пароль SSL-сертификата... и перезагрузка / запуск устраняет проблему. Оглядываясь в /var/log/messages, самые первые записи журнала сегодня:
Jun 30 05:17:40 localhost kernel: imklog 4.2.0, log source = /proc/kmsg started.
Jun 30 05:17:40 localhost rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="393" x-info="http://www.rsyslog.com"] (re)start
Jun 30 05:17:40 localhost rsyslogd: rsyslogd's groupid changed to 103
Jun 30 05:17:40 localhost rsyslogd: rsyslogd's userid changed to 101
Я предполагаю, что это означает, что это была перезагрузка, но я так мало знаю о реальном администрировании сервера, что я хотел это проверить. Я могу опубликовать остальную часть messages если бы это было полезно. Запись до этого была следующей один раз в день:
Jun 29 06:34:11 localhost rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="350" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Так что это указывает на перезагрузку сервера, как я предполагаю? Есть ли способ определить, что вызвало перезагрузку? Или если человек сделал это?
5 ответов
Самый простой способ увидеть, если он недавно перезагрузился, это просто набрать,
uptime
Если вы хотите проверить преднамеренные перезагрузки, введите:
lastlog
Если нет записи о преднамеренной перезагрузке или нажатии кнопки питания, но она была перезапущена, вам придется начать стандартную процедуру диагностики, чтобы выяснить, почему она перезапустилась. Начните с просмотра графиков сервера на предмет выделения памяти или ее перегрева. Есть довольно много вещей, которые могут вызвать случайные перезагрузки, которые не будут регистрироваться (паника ядра, сторожевой таймер и т. Д.), Но удаленная регистрация последовательной консоли даст вам эту важную информацию.
"Rsyslogd был HUPed" указывает, что процесс rsyslog перезапущен, и это последнее сообщение, потому что, по-видимому, раньше оно не работало, а rsyslog - это процесс, который обычно оставляет сообщения в журнале. Поэтому при перезапуске сообщения перезапускаются.
Возможно, это связано с известной ошибкой в Ubuntu, подробнее об этом можно прочитать здесь http://ubuntuforums.org/showthread.php?t=1384521
Хотя увы нечего подсказать, как это вылечить. Вполне возможно, что проблема rsyslog не связана с перезагрузками сервера.
uptime покажет вам, сколько времени прошло с момента последней перезагрузки.
last покажет вам последних зарегистрированных пользователей, а также обнаружит ли он обычный запрос на перезагрузку.
кто покажет вам кто вошел в систему сейчас. Убедитесь, что вы единственный, кто вошел в систему, или что вы можете учесть все подключения.
Более важны строки перед этой строкой системного журнала. Это может дать нам что-то, а может и нет. Свяжитесь с кем-либо, кто размещает ваш сервер, и узнайте, было ли у него какое-либо запланированное или незапланированное отключение питания или перезагрузка. Самое интересное не в том, что сервер был перезагружен, а в том, что это было сделано без вашего ведома. Также обратите внимание, что нестабильное или неисправное оборудование может иногда перезагружаться самостоятельно, поэтому вашим первым шагом должно быть обращение к вашему хостинг-провайдеру, чтобы узнать, сделали ли они это или обнаружили что-либо.
Это может означать перезагрузку. Из того, что вы дали нам, я действительно не могу сказать. Публикуемые вами журналы показывают, что процесс rsyslogd перезапущен (по сигналу HUP). Я не могу сказать, сделал ли это человек или программа, потому что оба могут послать сигнал HUP с правильными разрешениями.
Это именно тот журнал, который я вижу при запуске моей системы.
# cat /etc/redhat-release
CentOS release 6.4 (Final)
# cat /var/log/messages
Aug 19 12:04:22 [...] kernel: imklog 5.8.10, log source = /proc/kmsg started
[...]
Aug 19 11:49:17 [...] ntpd[935]: 0.0.0.0 c61c 0c clock_step -913.885823 s
Обратите внимание, что ntpd может изменить время, и это может изменить результаты uptime, По какой-то причине мой отчет сообщает на 40 минут меньше, чем истинное значение, хотя ntpd может объяснить только 15 минут разницы.