Обеспечение работы по ssh в случае отказа дисковой подсистемы

Средство мониторинга + сетевой KVM ...

1. Средство мониторинга тут причём? Я говорю не о диагностике, а о действиях после аварии.
2. Сетевой КВМ это да, это хорошо :) Он даже есть и даже должен работать, но не работает :(

ОСТОРОЖНО! Глупая идея!

А нельзя создать что-то типа RAM-диска, чтобы все нужные утилиты и ведро висели там? Т.е. пока питание есть - пофиг на винты. Как я это вижу: 1. Начинается загрузка. 2. Создаётся RAM-диск. 3. Загрузка продолжается с RAM-диска.

подпишусь, так как сам с таким иногда сталкиваюсь.
Насколько я понимая, демону или системе нужно записать логи (как я понимаю о логине), а так как места для записи нет, то все обламывается. В oracle на этот случай есть аккаунт sys или system, чьи действия не логируются и который, соответственно может зайти независимо от того, есть место под логи или нет.
Сделать отдельного такого пользователя для ssh думаю не получится, поэтому я думал в направлении полного отключения логирования.
Но так тесты не доведены до конца, понаблюдаю за успехами в этой теме

ФС разве не резервирует место руту?

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

Я пробовал как-то на одном сервере, с дебианом, у которого периодически умирает RAID (ну, я так думаю что это он ).
Насколько помню, при загрузке копировал в tmpfs папки /bin /var /tmp /lib и монтировал их вместо оригинальных. Но тогда это не помогло, или не всё перенёс в память, или дело было не в рэйде, или чего-то не учёл.

В bsd ssh продолжает работать после того как отваливаются контроллер и диск.
True story.

события сегодняшнего дня говорят мне об обратном

А если слинковать sshd статически?

При подключении с диска читаются исполняемые файлы и библиотеки

OH SHIT, ты хочешь сказать, при тысяче коннектов у меня будет висеть тысяча копий библиотек и исполняемых файлов?
Давай проверим? Вносите методику проверки

я хочу сказать что шелл вполне может тянуть за собой какую-нибудь «telephaty_autocompletion.so», которая ничем кроме этого шелла не используется.
но вообще, мысль единственно верная в этом случае посмотреть что грузится с диска при открытии ssh-сессии

посмотреть что грузится с диска при открытии ssh-сессии

как минимум /etc/profile ~/.profile или чтото специфичное для каждого шела

ssh + busybox + libs в RAM-диске

1. Средство мониторинга тут причём? Я говорю не о диагностике, а о действиях после аварии.

наверное, чтоб предупреждать аварии... (например кончается место на винте)

ssh -T

+1

Лучше в ramfs, так как tmpfs может уйти в swap. Хотя, если диск со swap'ом отвалится, а ядро захочет посвопится, будет паника.

Сделайте raid 1 для необходимого вам, на гигабайт, из 4/5/6/...100500 разделов, физически расположенных на как минимум двух жестких дисках.

Помимо вышеприведенных методов перемещения в RAM, можно сделать копию утилит на смонтированный cd/flash/etc

Ещё можно монтировать бинарники с библиотеками по сети. Пока есть сеть — будут использоваться извне, нет — прочитаются с диска.

sdio, mky
а какие есть варианты, если бинарники и библиотеки на месте, и просто нет места на диске
(т.е. скорее всего, просто не могут писаться логи)?

Насколько я понимая, демону или системе нужно записать логи (как я понимаю о логине)

Это же через syslog делается, sshd пофигу на это. Он же не отпадает, если syslogd остановить. :-)
А вот на что ему не пофиг, похоже, так это на LA немеряный...

Блин, ну тогда я не знаю что не так, раз все логи пишутся асинхронно и не на что не влияют. У меня есть еще теория про .history и wtmp, но, судя по всему, они тоже не виноваты

Блин, ну тогда я не знаю что не так, раз все логи пишутся асинхронно

Что-то все стормозили, включая меня. passwd-то недоступен...

Всё решилось установкой аппаратного watchdog и перезагрузкой в случае отказа.