sshd dead but pidfile exists

Посоветую погонять memtest. Если ФС была совсем в плохом состоянии, то может потребоваться несколько запусков fsck.

на примонтированном /

Примонтированном на запись или только на чтение?

на запись или только на чтение

rw

memtest

Аээ. А если бы с памятью чо было, разве syslog не сказал бы? Это же HP, там с мониторингом ECC-ошибок должно было хорошо все..

Кто что посоветует для отладки?

memtest, логи. Также можно включить создание core dump'ов и посмотреть от чего процессы помирают.

Пока план - скопировать с рейда данные на обычный винт и попробовать загрузиться (чтобы исключить аппаратные сбои диска)

Аппаратные сбои диска оставляют следы в логах и dmesg. ИМХО, крайне маловероятно.

Что за ОСь? Если что-то красноглазое ( arch, gentoo и т.п. ) - ССЗБ. Обновления ставил?

fsck

на запись или только на чтение

rw

Говорят у меня от этого брат умер...

Можно уточнить, о чем речь?

Я знаю, что fsck производит изменения в файловой системе, и поэтому крайне не рекомендуется запускать ее на примонтированный том, кроме того, fsck об этом честно предупреждает. Поэтому я запускал fsck с ключом -n.

Тут из саппорта пришел ответ, что, может, у нас память кончается, и эти демоны поубивала сама система.. Включим машину после праздников - надо будет проверить.

Интересно, а нафига swap делать на lvm-томе?

fsck с ключом -n.

А, ну тогда брат жив...

о чем речь?

Да это мем дурацкий.

запускал fsck с ключом -n.

Репорта по ошибкам вроде не было, хотя по окончании проверки оно сказало, что модифицировало ФС (наверное, журнал накатывало)

Насколько я понял man, оно при этом только сообщает и ничего не меняет. Если есть сомнения в диске, есть физический доступ до системы и есть возможность даунтайма то лучше бы перейти на первый уровень запуска, перемонтировать на только чтение и выполнить полноценную проверку.

Тут из саппорта пришел ответ, что, может, у нас память кончается, и эти демоны поубивала сама система..

А сколько там памяти?

мем

Мем знаю, пытался убедиться, что правильно понял, к чему его вспомнили.

сомнения

Сомнения там есть, но просто так их не проверить - там аппаратный рейд6 (возможно, в шапке треда немного другое написано, но после написания треда я ещё раз проверил), поэтому проверка fs будет только проверкой fs. А вот смарты посмотреть я бы не отказался, но боюсь, что для этого придется вскрывать сервак, а он на гарантии.

перемонтировать только на чтение

Это значит, что транзакции на запись из системы не законфликтуют с изменениями, которые произведет fsck? То есть fsck в любом случае получит доступ на запись, независимо от режима монтирования?

памяти

памяти там 24 гига..

что за ось

Центос 5.7 или 5.5, точно не помню. Обновлять не брался, так как могут отвалиться куски стороннего софта, зависимые от ядра (не уверен, что они там есть, но это вычислительный кластер, и там может быть все, что угодно - работы с ним были начаты не мной и до меня, так что я не в курсе всего).

memtest

Повторюсь, разве при ECC-ошибках сислог не матерится в wall? На другом кластере так и происходит, а на этом - не видел ни разу.

Сомнения там есть, но просто так их не проверить - там аппаратный рейд6

Насколько мне известно, некоторые контроллеры рейда позволяют узнать smart дисков. Но это всё, что я об этом знаю.

перемонтировать только на чтение

Это значит, что транзакции на запись из системы не законфликтуют с изменениями, которые произведет fsck? То есть fsck в любом случае получит доступ на запись, независимо от режима монтирования?

Насколько мне известно, лучше ФС не проверять когда она доступна на запись. Поэтому

mount -o remount,ro /
touch /1234

памяти там 24 гига..

Такой объём трудно забить до предела. Ну и в любом случае, есть free.

вычислительный кластер

А, ну тогда только free.

Тут из саппорта пришел ответ, что, может, у нас память кончается, и эти демоны поубивала сама система..

Исключено, это обязательно было бы в /var/log/messages.

Про просмотр смартов сквозь рейд-контроллеры погуглю, спасибо.

трудно забить

Вот в голову тупо не пришло. После того, как я узнал, сколько этой памяти, мне просто не приходило в голову, что ее можно забить чем-то, кроме пользовательских задач..

мертвые демоны

рейд

Это тред про Варкрафт? )

- да

- как пропатчить..

И что это значит? Старые пид файлы?

Запускать fsck на файловой системе, на которую идёт запись не имеет ни какого смысла и сообщение от fsck о том, что «filesystem contains errors» ни о чём не говорит. Для проверки систему перемонируют в ro, fsck споконо на неё пишет, так как работает с блочным устройство, а не с файловой системой.

там с мониторингом ECC-ошибок должно было хорошо все..

Должно быть или он есть? Может быть что угодно — вставлена левая память без ECC, или ECC отключен в BIOS, или первым умер klogd, который и пишет в syslogd. memtest даст нагрузку на память и процессор и как раз систему нужно было на праздники оставлять с запущенным memtest, а не в выключенном состоянии. По мне, один удачный проход memtest ничего не гарантирует, я обыно жду 10-20 успешных проходов, но если у вас там 24 Гбайт, то ждать будете долго.

Случайная «смерть» демонов по мне верный признак проблем с памятью. Если бы были повреждения исполняемых файлов, скорее всего бинарники бы вобще не запускались. OOM-killer прибивает демонов работающих от root'а в пользу памяти, необходимую пользовательскому процессу только в случае, если этот пользовательский процесс «кушает» память медленно, а процессор сильно. Помимо наличия записей в log'ах память остаётся сожранной и с системой работать не получится — нет памяти для запуска bash или комманд в bash'е да ещё swap'инг.

систему нужно было на праздники оставлять с запущенным memtest, а не в выключенном состоянии

Увы, не я решаю - это госконтора, поэтому там на праздниках не будет никого, кроме дежурных инженеров, а это люди, которые градусник-то не всегда находят на стенке шкафа, так что такую технику на них лучше не оставлять.

В общем, погляжу на память повнимательнее..

но боюсь, что для этого придется вскрывать сервак, а он на гарантии.

Я не видел серверов с опломбированным корпусом. Открывали, пылесосили, на гарантию это не влияло. Но аппаратный RAID подразумевает диски с горячей заменой, снимаемые без вскрытия корпуса. Разве что там может оказаться SAS, а не SATA и вам будет не где их прочитать.

И ещё, некоторые аппаратные RAID'ы замечают что диск был вытащен и не принимают его обратно (только пересинхронизация), поэтому вытаскивайте/вставляйте по одному диску и проверяйте, что RAID остаётся целым.

Есть наклейка на винте, который держит крышку.

Диски, может, и правда наружу торчат, что-то мне в голову не пришло, хотя логично же..

SAS можно в другой сервер вставить, если что.