Dlaczego aktualizacja działającego systemu Linux nie stanowi problemu?

Lata używam na co dzień systemów Linux i nigdy nie miałem większych problemów z aktualizacją systemu, gdy był uruchomiony, ale wciąż zastanawiam się, dlaczego jest to możliwe.

Pozwól mi zrobić przykład.

Załóżmy, że program „A” z określonego pakietu działa w systemie. Ten program w pewnym momencie musi otworzyć inny plik („B”) z tego samego pakietu. Następnie program „A” zamyka „B”, ponieważ już go nie potrzebuje. Załóżmy, że teraz aktualizuję pakiet „A” i „B” należą. Operacje te nie mają bezpośredniego wpływu na „A”, przynajmniej na chwilę, ponieważ działa on w pamięci RAM, a aktualizacja właśnie zastąpiła „A” na dysku twardym. Załóżmy, że „B” również zostało zastąpione w systemie plików. Teraz „A” musi z jakiegoś powodu ponownie przeczytać „B”. Pytanie brzmi: czy jest możliwe, że „A” może znaleźć niezgodną wersję „B” i spowodować awarię lub usterkę w inny sposób?

Dlaczego nikt nie aktualizuje swoich systemów po ponownym uruchomieniu z CD na żywo lub podobną procedurą?

Aktualizacja Userland rzadko stanowi problem

Często można aktualizować pakiety w systemie na żywo, ponieważ:

1. Udostępniane biblioteki są przechowywane w pamięci, a nie odczytywane z dysku przy każdym wywołaniu, więc stare wersje będą w użyciu do momentu ponownego uruchomienia aplikacji.
2. Otwarte pliki są w rzeczywistości odczytywane z deskryptorów plików , a nie z nazw plików, więc zawartość pliku pozostaje dostępna dla uruchomionych aplikacji, nawet po przeniesieniu / zmianie nazwy / usunięciu do momentu nadpisania sektorów lub zamknięcia deskryptorów plików.
3. Pakiety wymagające ponownego załadowania lub ponownego uruchomienia są zazwyczaj poprawnie obsługiwane przez menedżera pakietów, jeśli pakiet został dobrze zaprojektowany. Na przykład Debian zrestartuje niektóre usługi przy każdej aktualizacji libc6.

Zasadniczo, chyba że aktualizujesz jądro i nie używasz ksplice, programy lub usługi mogą wymagać ponownego uruchomienia, aby skorzystać z aktualizacji. Jednak rzadko trzeba ponownie uruchamiać system, aby zaktualizować cokolwiek w obszarze użytkownika, chociaż na komputerach jest to czasami łatwiejsze niż ponowne uruchomienie poszczególnych usług.

Zobacz też

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

Tak, to co opisałeś jest możliwe, ale przez większość czasu, jeśli plik jest dołączony do pakietu, będzie to biblioteka lub inny plik, który będzie czytany tylko raz (ponieważ się nie zmienia, nie ma powodu, aby przeczytaj to wiele razy). Również jeśli plik jest potrzebny długoterminowo, aplikacja prawdopodobnie pozostawi otwarty uchwyt pliku, w którym nawet jeśli zostanie zastąpiony w rzeczywistym systemie plików, otwarty uchwyt pliku pozostawi starą wersję otwartą.

W większości przypadków wszelkie dane, które są odczytywane wiele razy w trakcie procesu, są danymi użytkownika / zmiennych i nie zmieniłoby się to podczas aktualizacji pakietu. Ponadto, ponieważ dane są zmienne, każdy programista przy zdrowych zmysłach upewniłby się, że program poradzi sobie z nimi, zmieniając się z jednego odczytu na drugi.

Załóżmy, że „B” również zostało zastąpione w systemie plików. Teraz „A” musi z jakiegoś powodu ponownie przeczytać „B”. Pytanie brzmi: czy jest możliwe, że „A” może znaleźć niezgodną wersję „B” i spowodować awarię lub usterkę w inny sposób?

Jest to możliwe, ale w większości przypadków mało prawdopodobne. Jeśli „B” jest biblioteką kodów, oryginalna wersja zwykle nie byłaby zamknięta. „A” będzie nadal używać oryginalnej wersji „B”. Jeśli po aktualizacji uruchomisz „A”, zostanie użyta nowa wersja „B”. Podczas aktualizacji istnieje ryzyko, że zostaną załadowane niezgodne wersje. Jednak ze względu na sposób ładowania bibliotek kodów powinno to stanowić problem tylko wtedy, gdy „A” potrzebuje funkcji nieobecnej w załadowanych wersjach „B”.

Dobra praktyka kodowania utrzymuje ten sam interfejs dla funkcji. W rezultacie nie ma większego znaczenia, która wersja jest załadowana, poza tym, czy w nowszej wersji zostały naprawione błędy.

Pliki konfiguracyjne to nieco inna sprawa, ale zwykle są odczytywane podczas uruchamiania. W takim przypadku „A” nie odczytuje „B”, chyba że zmienione zostanie ponowne ładowanie konfiguracji. Ponownie zmiana formatu lub znaczenia pliku konfiguracyjnego byłaby złą praktyką kodowania. Niezgodna wersja pliku konfiguracyjnego powinna mieć inną nazwę, aby nie stanowiło problemu.

Dlaczego nikt nie aktualizuje swoich systemów po ponownym uruchomieniu z CD na żywo lub podobną procedurą?

Wyłączenie i ponowne uruchomienie z innej wersji doprowadziłoby do awarii usługi. W przypadku serwerów zazwyczaj nie jest to pożądane. W każdym razie menedżer pakietów w uruchomionym systemie jest świadomy zainstalowanego oprogramowania i wersji. Live CD mają tam własną listę zainstalowanych programów, być może z różnymi wersjami. Utrudnia to niezawodne uaktualnienie działającego systemu z Live CD.

Live CD są czasami używane, gdy instalowana jest nowa wersja systemu operacyjnego. W takim przypadku zwykle wykonuje się czystą instalację systemu operacyjnego. Może to ograniczyć liczbę nieużywanych plików z poprzedniej wersji. Może to być większy wysiłek niż aktualizacja systemu na żywo. Jeśli jednak zostaną zastosowane różne partycje główne, może to ograniczyć ryzyko utknięcia w częściowo zaktualizowanym systemie, którego nie można uruchomić.

W niektórych przypadkach jest to problem:

• Uaktualnienie JDK podczas działania maszyny wirtualnej Java: Zadałem myselv to samo pytanie, które otrzymałeś - miałem działającego kocura korzystającego z Java. Teraz po aktualizacji łatki JDK nadal działał bez problemów - tak się wydawało.

Teraz wyjaśnieniem jest pamięć podręczna. OK - uruchomiłem program do zapamiętywania pamięci, aby zużyć całą dostępną pamięć RAM - i wtedy Tomcat się zawiesił (po uzyskaniu dostępu do uruchomionej tam aplikacji).

• Aktualizacja jądra w systemach SuSE: W SuSE stare jądro i jego moduły są usuwane zaraz po aktualizacji łatki do jądra. Jeśli chcesz użyć czegoś nowego, wymagającego modułu jądra, który nie był do tej pory załadowany, usługa zakończy się niepowodzeniem.