У меня есть веб-сервер, который, я думаю, в какой-то момент перезагрузился ... в основном потому, что 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'.
Означает ли это перезагрузку сервера, как я предполагаю? Есть ли способ определить причину перезагрузки? Или если это сделал человек?
Самый простой способ узнать, перезагружался ли он недавно, - это просто набрать,
uptime
Если вы хотите проверить преднамеренные перезагрузки, введите,
lastlog
Если нет записи о преднамеренной перезагрузке или нажатии кнопки питания, но при этом перезапуск был произведен, вам придется начать стандартную диагностическую процедуру, чтобы выяснить, почему он был перезапущен. Начните с просмотра графиков серверов ar на предмет перераспределения или перегрева памяти. Есть довольно много вещей, которые могут вызвать случайные перезагрузки, которые не будут регистрироваться (паника ядра, сторожевой таймер и т. Д.), Но удаленная регистрация последовательной консоли даст вам эту жизненно важную информацию.
«Rsyslogd was HUPed» указывает, что процесс rsyslog перезапущен, и это последнее сообщение, потому что, по-видимому, оно не работало раньше, а rsyslog - это процесс, который обычно оставляет сообщения в журнале. Поэтому при перезапуске сообщения перезапускаются.
Возможно, это связано с известной ошибкой Ubuntu, вы можете прочитать об этом здесь. http://ubuntuforums.org/showthread.php?t=1384521
Хотя увы нечего подсказать, как это вылечить. Вполне возможно, что проблема с rsyslog не связана с перезагрузкой сервера.
Это может указывать на перезагрузку. По тому, что вы нам дали, я действительно не могу сказать. Опубликованные вами журналы показывают, что процесс 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 минут разницы.