Несколько месяцев назад наш сервер начал отказывать каждые 14 дней в одно и то же время (каждый раз около 11:04). Мы уверены, что это не какой-то аппаратный сбой, поскольку аппаратные сбои, как правило, бывают случайными.
Сервер просто внезапно перестает отвечать и перезагружается через несколько секунд. Ни один из журналов не содержит никакой связанной информации, и мы на 100% уверены, что на сервере нет cron, который мог бы вызвать это.
Кто-нибудь когда-нибудь сталкивался с такой проблемой? Мы очень расстроены этим проводным поведением, так как нет даже единой подсказки, что не так ...
Я также снял видео прямо перед тем, как сервер выйдет из строя, как вы можете видеть, ничего плохого не было ...
Обновление 11 апреля 2011 г .:
2 недели назад : Чтобы сузить возможности, сервер был отключен (shutdown -h now) за 5 минут до следующего события. И сервер волшебным образом загрузился сам в ожидаемое время. После этого наш DC переместил сервер на другой порт PDU, мы думали, что это наконец решит нашу проблему.
Cегодня : Сервер все еще завис, в то же самое время !! Наш DC сказал, что другие серверы на том же PDU не имеют этой проблемы. Теперь мы действительно сбиты с толку, если это не PDU или наш сервер, что это может быть?
У меня была такая же ситуация, когда оба кабеля питания сервера были подключены к одним и тем же ИБП. После просмотра журналов ИБП сброс действительно произошел, когда ИБП выполняли самотестирование - каждые 14 дней.
Решение: подключите один шнур питания к другому ИБП или подключите его напрямую.
Из видео похоже на холодную перезагрузку. И как вы сказали, в логах ничего нет. Все, о чем я могу думать, - это «волшебный» ключ sysrq или неисправная карта kvm, если никакие другие серверы, использующие тот же ИБП, не испытывают то же самое.
Ошибочный / неисправный процесс мониторинга системы может происходить в определенные дни / часы. Это должно быть интересно отследить.
Первым шагом было бы изменить дату и время ОС и посмотреть, перезагружается ли она сама по себе, чтобы вы могли сузить ее.
Что именно вы подразумеваете под «точно в то же время»?
Предполагая, что вы устранили все запланированные задания (изменив время их выполнения, а не просто просматривая журналы), то в верхней части моего списка будут просматриваться журналы UPS. Вы делать есть ИБП, не так ли?
Я действительно видел, как кто-то делал это в cron, просто чтобы увеличить количество обращений в службу поддержки. Вам обязательно нужно проверить и убедиться, что в системе явно не запланировано ничего, что могло бы вызвать такого рода проблемы.
Что говорят системные журналы?
У меня был сервер IBM, который падал каждые 76 дней. Сводили меня с ума от разочарования, пытаясь понять это. Оказалось, проблема с часами на одной из системных карт (http://communities.vmware.com/thread/9359). На всякий случай обязательно проверьте, не возникало ли у кого-нибудь подобных проблем с сервером марки и модели.
Если на сервере есть внешний BMC, проверьте журналы BMC. Возможно, таймер BMC настроен на 24 часа, и он не сбрасывается ОС (все же многие BMC сначала пытаются корректно завершить работу)
Сначала попробуйте выключить crond день крушения. (Я подозреваю, что задание cron в 11 утра, выполнение которого занимает четыре минуты, вызывает ошибку ядра или аппаратный сбой.)
Кроме того, попробуйте замедлить системные часы на три минуты, чтобы проверить, вызвана ли проблема чем-то внутри сервера или внешним по отношению к серверу.