>> пакеты главное продолжали летать
> А почему они должны были перестать это делать? Ну да, ядро то живое и плевало оно на этот libc... ;)
> Была похожая ситуевина, на полноценном компе конечно,
В моем случае - примитивный манагер пакетов openwrt ступил при каком-то сильном изменении в trunk и решил при форсированном обновлении бойко выпилить libc по этому поводу :)). Грех жаловаться, ибо trunk сам по себе постоянно крушат и ломают, а я еще и решил форсануть сомнительное обновление на свой зад. На которое opkg упирался. Как бы логично что я получил невкусный результат, хотя, конечно, настолько нахальной и убойной системной диверсии я все-таки не ожидал :)
> но тем не менее, часть похеренных файлов удалось восстановить,
> из ссылок в /proc/pid/fd,
После упомянутого действа перестали запускаться и работать абсолютно все команды в системе. Я остался в ssh, пакеты продолжили летать. Но ни одна команда не работала. Получился всадник без головы :). В результате - подождал до момента когда выключение роутера не будет создавать никаких проблем и ребутанул с зажатой кнопкой в "failsafe" режим. У openwrt есть такой режим - если оно при загрузке видит что нажата кнопка, монтируется только дефолтный readonly squashfs, а (потенциально проблемные) изменения юзера в (read-write) JFFS - не монтируются "поверх" readonly базовой системы. Поэтому мы получаем систему в максимально дефолтном виде, какой она была на момент билдования образа. А далее уже замаунтить JFFS уже "в сторонку", не приводя систему в текущее состояние, но получив ФС с изменениями "где-то сбоку". Далее из этой ФС можно без проблем вынуть нужные файлы или поупражняться в откате нежелательных изменений. Что и было сделано.
> для оставшихся запущенными демонов, естественно,
> с либами конечно было не так просто. Кстате, systemd могла бы
> решать эту проблему наличием ссылок на либы по аналогии.
Я не вижу причин почему системные либы должно бы быть нельзя стирать при апдейте или почему это не должно бы затронуть программы. Единственное что тут было неправильно в моем понимании - действия пакетного манагера. Пакетный манагер по определению должен иметь доступ во все закоулки системы и потому должен иметь возможность да хоть тот же systemd и выпилить, если так было решено. Но желательно во первых сказать что будет выпилен критичный пакет, а во вторых - не делать данное действо при обычном обновлении системы, а только если юзер попросит вручную именно действо это и подтвердит грозный варнинг.
> Совсем не при чем, но демон отвечающий за взаимодействие компонентов системы, должен
> бы похвастаться нативной поддержкой запуска, скажем nginx со статической страничкой с
> информацией о технических проблемах на сайте,
Какой-то сильно кастомный функционал. А, простите, зачем бы его пичкать вообще во всех? От эмбеддовки с 16М памяти до десктопов где никакого опача нет? ИМХО, сильно кастомная хотелка, ну вот вы и занимайтесь кастом кодингом оной в каком-то вашем супердистре, откровенно ориентированном на сервера, только сервера, при том только сервера которым нужен нжинкс и опач одновременно (нжинкс вполне может и без апача обойтись, btw).
> до момента запуска апача со всеми его наворотами и, вероятно необходимыми
>для запуска файлами, лежащими вне стандартных директорий (где-нить
> на шифрованных файло-разделах смонтированными по сети),
Вы описываете нечто, что врядли окажется даже в 1% машин. Какого хрена это надо по дефолту вдувать всем? И почему у остальных 99% ненужный им функционал должен хавать место на винте, в оперативке и прочая? А как обрабатывать ситуации если у юзера нет апача или нжинкса? А кто сказал что они обязаны быть в каждой инсталляции? Как максимум, демон отвечающий за старт сервисов мог бы как-то немного упрощать подобные вещи, но решать все проблемы как серебряные пули? Упаси боже. Он тогда превратится в операционку в операционке :)
> то есть не десктоп-ориентированный hald с базой данных моделей-флэшек, и не
> то уродство, что сейчас пилит RH, с оптимизацией /var/run, а полноценная
> псевдо-фс с возможностью проверки - слушает ли dhcpd udp порт на
> таком-то интерфейсе, или же интерфейс не "поднялся" на момент старта этого
> демона и демон на него забил ругнувшись в лог...
Можно пойти чуть дальше :P. Вот например, можно захотеть проверить насколько он жив более эффективным методом :). А то вдруг dhcpd впал в infinite loop и хоть и открыл порт, но далее сдох и забивает на запросы гоняя infinite loop и более ничего? Это же тоже жопа, правда? :). А пусть запускач будет содержать целый настоящий дхцп-клиент и получит себе персональный айпишник от дхцп. Провалидировав работу демона от и до :) На манер assert(condition) используемого в программах. Ну и что что в итоге запускач превратится в некий гибрид среды программирования и операционной системы, т.к. без этого нужной гибкости просто не достичь? Будет Linux-on-Linux (LoL). Ну типа как Windows on Windows (WoW) :))). Тем более что название для этой подсистемы обещает доставлять :)
