В первом экземпляре был Centos 5.4 (64-бит), много ресурсов, установлен Hudson (http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson) и все было хонкей-дорей. Через несколько дней или недель (не могу вспомнить, какой именно) весь сервер случайным образом зависнет, что потребует жесткой перезагрузки. На нем не было ничего, кроме ресурсов, необходимых для Хадсона.
Новый концерт: свежеустановленный Centos 5.5 (64-бит). Примерно через месяц снова начались заморозки. Без видимой причины.
У нас есть идентичные серверы, работающие повсюду, обслуживающие все, от Tomcat до Jboss и базовых вещей Apache, и все это без зависаний и сбоев.
Кажется, проблема в Hudson - мы просто не можем понять, чем он отличается от типичных конфигураций.
Итак, 2 вопроса:
Лучший способ, который я нашел, - это вести какой-то журнал в реальном времени по сети или через последовательное соединение. Иногда ядро может вывести критическое сообщение в оболочку, вошедшую в систему, даже если оно не может сохранить его в файл, поэтому просто открытие удаленной оболочки может помочь. Вы также можете использовать -f для определенных файлов журнала или, что еще лучше, cat / proc / kmsg и просматривать живые сообщения ядра, отправленные по ssh. Другой более надежный вариант - настроить физический последовательный порт в качестве консоли. У меня все мои серверы поддерживают последовательную консоль и могу регистрировать всю загрузку с помощью эмулятора последовательного терминала, такого как HyperTerminal или, что лучше, PuTTY на последовательном порту. Добавление опции загрузки console = ttyS0 отправит все сообщения ядра в COM1, который требует намного меньше работы по сравнению с поддержанием сетевого соединения. Большинство материнских плат обычно имеют на плате разъем для COM1, даже если у них нет разъема.