Нет

что то похожее было

kexec tools

кстати, это касается не только ядра

вот обновил я жёстко мир, отдал команду - и параллельно загрузилась новая система

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

Ksplice. но пока непонятно, насколько этой мегатехнологии можно верить.

А главное зачем это нужно

Так это, kexec..? Только за самоуничтожение он не отвечает точно (хотя, если повезёт).

kexec?

это только для ядра

Ну при изменении всяких libc, перезагрузка все-равно понадобится.
Так что, если в контексте всей системы, а не только ядра, то нет, такой технологии нет.

http://en.wikipedia.org/wiki/Kexec

http://uk.wikipedia.org/wiki/Kexec

kexec explained

kexec := перезагрузка, но без POST.

Этим делом может заниматься гипервизор, например, но я что-то не уверен, что он сможет перетащить процесс с его контекстом под новую глибц без глюков. Стабильное API, мать его, такое нестабильное.

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

>резко - рраз! - и перескочило всё на этот новый вариант
Что значит «перескочило»?
Новая система загрузилась до какого-то состояния в фоне, после чего старая просто выгрузилась и передала контроль новой?

Или к тому же все старые процессы должны запустить свои новые версии и привести их к старому состоянию?

да

>скомпилил я новое ядро, положил его на место, отдал команду - и параллельно с уже загруженной системой в память загружается новый вариант системы с новым ядром

quemu virtualbox же, ну.

>кстати, это касается не только ядра

Практически всё, кроме смены ядра итак меняется, штатно. Без перезагрузки. Если это не Ubuntu, конечно :)

чем тут поможет виртаулбокс?

и даже такие вещи, как glibc?

После пересборки программы и зависимых библиотек необходимо её убить и запустить заново.
Иначе никак.

>и даже такие вещи, как glibc?

Если у какого-то приложения уже открыт старый glibc, то оно так и будет работать дальше после удаления (файлы старой версии будут удерживаться системой). При запуске новых приложений они будут линковаться уже с новой версией.

Fail может быть только если старая программа не совместима с новым glibc и не была обновлена - тогда она при запуске будет падать или глючить. Но это очень редкая история. В Gentoo я периодически обновляю glibc с 2004-го года и специально ради такого обновления не перезагружался никогда. Обновил glibc, пересобрал всё, что требуется по revdep-rebuild и работаешь дальше.

>После пересборки программы и зависимых библиотек необходимо её убить и запустить заново

Да нет, если она не будет линковаться к glibc уже во время работы - то будет прекрасно и дальше работать со старой версией glibc.

>будет ... и дальше работать со старой версией glibc.

Это я и имел в виду.

Буду писАть более распространёнными предложениями.

>Если у какого-то приложения уже открыт старый glibc, то оно так и будет работать дальше после удаления (файлы старой версии будут удерживаться системой). При запуске новых приложений они будут линковаться уже с новой версией.

наверное, ты меня не очень понял, смотри: есть некоторое кол-во памяти, допустим, 4 Гб. Запущенная система занимает, к примеру, 1,5 Гб. Помимо самой системы (ядра, системного окружения, иксов, кед), загружен браузер с открытой страничкой, окуляр с открытым документом, амарок с песенкой на паузе. Итак, мы обновили систему/мир вместе с ядром. Отдаём команду перезагрузки. Вместо завершения работы системы и аппаратного ресета с последующей загрузкой «с нуля», авторизацией и восстановлением рабочего сеанса, система создаёт в памяти изолированную область, в которую загружает новый вариант системы, с новым ядром и всем прочим. Также она восстанавливает все открытые в нынешней системе программы. Когда загрузка обновлённой системы завершается, пользователь начинает работать с ней (так сказать, фокус переходит в эту изолированную область памяти), а старая система уничтожается в памяти. Быстро и удобно.

>наверное, ты меня не очень понял

Я совсем о другом говорил. Об обновлении библиотек без рестарта системы. Благодаря чему практически всё, кроме замены ядра, можно подменять без перезагрузки и сейчас, без всяких хитростей.

А вот с ядром так в общем случае не прокатит. Хотя бы из-за проблем эксклюзивной работы с железом.

>Хотя бы из-за проблем эксклюзивной работы с железом

ты имеешь в виду прямой доступ к железу? разве это такая уж проблема?

Fail может быть только если старая программа не совместима с новым glibc и не была обновлена - тогда она при запуске будет падать или глючить. Но это очень редкая история.

Но это очень редкая история для source-based дистрибутивов. В бинарных это встречается достаточно часто в нестабильных ветках.

Тут ещё одна проблема - доступ к данным на фс.
Ну допустим можно быстро склонировать используемые фс используя что-то типа cow или подобное. Но в итоге у нас получится два экземпляра фс.
Как их потом корректно синхронизировать?

Мне кажется лучше смотреть в сторону, когда не нужно вообще перезагружаться. Например допилить ksplice до состояния, чтобы можно было переходить с одной версии ядра на другую без проблем, тогда и ребут не понадобится.

>вот обновил я жёстко мир, отдал команду - и параллельно загрузилась новая система
параллельно никак, но можно «shutdown now», тогда все программы перезапустятся, кроме инита и ядра

Я представляю этот процесс так:

Система временно приостанавливается, состояние ОЗУ и прочее сохраняется (можно воспользоваться наработками hibernate), локальные фс клонируются посредством cow или подобным.

Основная система возвращается к обычному состоянию.

В гипервизор монтируются клонированые фс и разворачивается сохранённое состояние. Не знаю как это будет работать, т.к. «железо» поменялось.

Далее система в гипервизоре перезагружается хотябы просто до логин скрина.

Теперь обе системы приостанавливаются и фс каким-то образом синхронизируются (хз как).
Можно тупо слить все изменения из гипервизора, но тогда все изменения сделанные после старта процесса живой перезагрузки будут потеряны.

Система в гипервизоре отправляется в хибернейт.

Гостевая система, наплевав на всё восстанавливает состояние из гипервизора. (диски уже синхронизированы)

Профит!

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

Дискасс.

Практически всё, кроме смены ядра итак меняется, штатно. Без перезагрузки. Если это не Ubuntu, конечно :)

А чем убунта в данном случае отличается от остальных дистрибутивов? Вроде там всё так же.

>А чем убунта в данном случае отличается от остальных дистрибутивов?

А фиг его знает. Но там во время обновления могут обрушиться иксы. И, вообще, вот так бывает: http://www.linux.org.ru/forum/talks/4941729

Ну и дальше комменты в теме, типа http://www.linux.org.ru/jump-message.jsp?msgid=4941729&cid=4941910 :)

...

Но там во время обновления могут обрушиться иксы.

Скорее GDM какой-нибудь. Кеды и гномы очень чувствительны к изменению файлов с данными во время работы.

А вообще у меня однажды иксы ушли в сегфолт при удалении (вручную, rm'ом) synaptics_drv.so, когда я его хотел заменить на свою патченную версию. Причём дело было под gentoo.

P.S. Ковыряю убунту в виртуалке уже больше месяца. Правда без иксов. Пока никаких проблем не замечено.

>Кеды и гномы очень чувствительны к изменению файлов с данными во время работы.

В Gentoo я, бывало, месяцами сидел без рестарта иксов, хотя за это время менялась версия Gnome :) Перезагрузишься иногда - опаньки, Gnome какой-то другой! :D

>есть ли в Линуксе технологии
а в какихто других системах есть?