Чому оновити працюючу систему Linux не проблематично?

Ми роками користуюсь системами Linux щодня, і я ніколи не мав великих проблем з оновленням системи, коли вона працювала, але я все ще дивуюсь, чому це можливо.

Дозвольте зробити приклад.

Припустимо, що програма "А" з певного пакета працює в системі. Цій програмі в певний момент потрібно відкрити ще один файл ("B") з того ж пакету. Після цього програма "A" закриває "B", оскільки вона вже не потрібна. Припустимо, тепер я належу до оновлених пакетів "А" та "В". "A" не впливає безпосередньо на ці операції, принаймні на даний момент, оскільки він працює в оперативній пам'яті, а оновлення просто замінило "A" на жорсткому диску. Припустимо, "B" замінено і у файловій системі. Тепер "А" чомусь потрібно знову прочитати "В". Питання: чи можливо, що "A" зможе знайти несумісну версію "B" та вийти з ладу чи несправності якимось іншим способом?

Чому ніхто не оновлює свої системи, перезавантажившись із живого компакт-диска чи якоїсь подібної процедури?

Оновлення Userland рідко є проблемою

Ви можете часто оновлювати пакети в реальній системі, оскільки:

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

Як правило, якщо ви не оновлюєте своє ядро ​​і не використовуєте ksplice, можливо, програми або послуги потрібно буде перезапустити, щоб скористатися оновленням. Однак рідко виникає необхідність перезавантажувати систему, щоб оновлювати що-небудь у користувальницькій країні, хоча на робочих столах це час від часу простіше, ніж перезапуск окремих служб.

Дивись також

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

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

У більшості випадків будь-які дані, які читаються кілька разів протягом життя процесу, є користувачами / змінними даними, і це не зміниться під час оновлення пакету. Крім того, оскільки дані мінливі, будь-який програміст з розумом переконається, що програма може впоратися з цим, змінюючись від одного читання до іншого.

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

Це можливо, але малоймовірно в більшості випадків. Якщо "B" є бібліотекою кодів, то початкова версія зазвичай не закрита. "A" продовжує використовувати початкову версію "B". Якщо після оновлення запустити "A", буде використана нова версія "B". Під час оновлення існує певний ризик завантаження несумісних версій. Однак через те, як завантажуються бібліотеки коду, це має бути проблемою лише у тому випадку, коли "A" потребує функціональності, відсутнього у завантажених ним версіях "B".

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

Файли конфігурації - дещо інша справа, але вони зазвичай читаються під час запуску. У цьому випадку "A" не буде читати "B", якщо б не було змінено перезавантаження конфігурації. Знову ж, було б поганою практикою кодування змінити формат або значення файлу конфігурації. Несумісна версія файлу конфігурації повинна мати інше ім'я, тому це не спричинить проблем.

Чому ніхто не оновлює свої системи, перезавантажившись із живого компакт-диска чи якоїсь подібної процедури?

Відключення та перезавантаження з іншої версії призведе до відключення служби. Для серверів це, як правило, не бажано. У будь-якому випадку менеджер пакунків у запущеній системі знає про встановлене ним програмне забезпечення та версії. Живі компакт-диски мають власний список встановленого програмного забезпечення, можливо, з різними версіями. Це ускладнює надійне оновлення запущеної системи з прямого CD.

Живі компакт-диски іноді використовуються, коли встановлюється новий випуск O / S. У цьому випадку зазвичай робиться чиста установка O / S. Це може обмежити кількість невикористаних файлів із попередньої версії, що зберігається. Це може бути більше зусиль, ніж оновлення живої системи. Однак якщо використовуються різні кореневі розділи, це може обмежити ризик застрягти з незавантаженою частково оновленою системою.

Існують деякі випадки, коли це проблема:

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

Тепер пояснення - кеш-пам'ять. Гаразд - я запустив програму пам’яті-hog, щоб використати всю наявну оперативну пам’ять - і тоді tomcat зазнав аварії (після того, як я отримав доступ до програми, що працює там).

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