Почему обновление работающей системы Linux не вызывает проблем?

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

Позвольте мне привести пример.

Предположим, что в системе запущена программа «А» из определенного пакета. Эта программа в определенный момент должна открыть другой файл ("B") из того же пакета. После этого программа «А» закрывает «В», потому что она больше не нужна. Предположим, теперь я обновляю пакеты «А» и «В», к которым относятся. «A» не затрагивается напрямую этими операциями, по крайней мере, на данный момент, так как он работает в оперативной памяти, а обновление только заменило «A» на жестком диске. Предположим, что «B» также была заменена в файловой системе. Теперь по какой-то причине «А» нужно снова прочитать «В». Вопрос заключается в следующем: возможно ли, что «А» может найти несовместимую версию «В» и аварийно завершить работу или выйти из строя каким-либо другим способом?

Почему никто не обновляет свои системы, перезагружая их с живого CD или с помощью подобной процедуры?

Обновление Userland редко является проблемой

Вы можете часто обновлять пакеты в действующей системе, потому что:

1. Общие библиотеки хранятся в памяти, а не читаются с диска при каждом вызове, поэтому старые версии будут оставаться в использовании до перезапуска приложения.
2. Открытые файлы фактически считываются из файловых дескрипторов , а не из имен файлов, поэтому содержимое файла остается доступным для запущенных приложений, даже когда они перемещены / переименованы / удалены, пока сектора не будут перезаписаны или файловые дескрипторы не будут закрыты.
3. Пакеты, которые требуют перезагрузки или перезапуска, обычно обрабатываются менеджером пакетов правильно, если пакет был хорошо спроектирован. Например, Debian будет перезапускать определенные сервисы всякий раз, когда обновляется libc6.

Как правило, если вы не обновляете свое ядро ​​и не используете ksplice, программы или службы могут быть перезапущены, чтобы воспользоваться преимуществами обновления. Тем не менее, редко требуется перезагрузка системы для обновления чего-либо в пользовательской среде, хотя на настольных компьютерах это иногда проще, чем перезапуск отдельных служб.

Смотрите также

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode

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

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

Предположим, что «B» также была заменена в файловой системе. Теперь по какой-то причине «А» нужно снова прочитать «В». Вопрос заключается в следующем: возможно ли, что «А» может найти несовместимую версию «В» и аварийно завершить работу или выйти из строя каким-либо другим способом?

Это возможно, но маловероятно в большинстве случаев. Если «B» является библиотекой кода, то исходная версия обычно не будет закрыта. «А» будет продолжать использовать оригинальную версию «В». Если вы запустите «A» после обновления, будет использоваться новая версия «B». Во время обновления существует риск того, что несовместимые версии могут быть загружены. Однако из-за способа загрузки библиотек кода это должно стать проблемой только в том случае, если «А» нужна функциональность, отсутствующая в загруженных им версиях «В».

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

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

Почему никто не обновляет свои системы, перезагружая их с живого CD или с помощью подобной процедуры?

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

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

Есть несколько случаев, когда это проблема:

• Обновление JDK при работающей java-VM: я задал myselv тот же вопрос, что и вы, - у меня был запущенный tomcat, использующий java. Теперь после патча-обновления JDK он все еще работал без проблем - так казалось.

Теперь объяснение кеш-памяти. ОК - я запустил программу памяти-поглотителя, чтобы использовать всю доступную оперативную память, а затем произошел сбой tomcat (после того, как я получил доступ к запущенному там приложению).

• Обновление ядра на SuSE-системах. На SuSE старое ядро ​​и его модули удаляются сразу после обновления ядра. Если затем вы захотите использовать что-то новое, для чего требуется модуль ядра, который не был загружен до сих пор, служба не будет работать.