Warum ist die Aktualisierung eines laufenden Linux-Systems nicht problematisch?

Es ist Jahre her, dass ich täglich Linux-Systeme benutze, und ich hatte nie größere Probleme, ein laufendes System zu aktualisieren, aber ich frage mich immer noch, warum dies möglich ist.

Lassen Sie mich ein Beispiel geben.

Angenommen, ein Programm "A" aus einem bestimmten Paket wird auf einem System ausgeführt. Dieses Programm muss zu einem bestimmten Zeitpunkt eine andere Datei ("B") aus demselben Paket öffnen. Danach schließt Programm "A" "B", weil es es nicht mehr benötigt. Angenommen, ich aktualisiere jetzt das Paket, zu dem "A" und "B" gehören. "A" ist zumindest vorerst nicht direkt von diesen Vorgängen betroffen, da es im RAM ausgeführt wird und das Update gerade "A" auf der Festplatte ersetzt hat. Angenommen, "B" wurde auch im Dateisystem ersetzt. Jetzt muss "A" aus irgendeinem Grund wieder "B" lesen. Die Frage ist: Ist es möglich, dass "A" eine inkompatible Version von "B" findet und auf andere Weise abstürzt oder nicht funktioniert?

Warum aktualisiert niemand seine Systeme durch einen Neustart mit einer Live-CD oder einem ähnlichen Verfahren?

Das Aktualisieren von Userland ist selten ein Problem

Sie können Pakete auf einem Live-System häufig aktualisieren, weil:

1. Freigegebene Bibliotheken werden im Arbeitsspeicher gespeichert und nicht bei jedem Aufruf von der Festplatte gelesen, sodass die alten Versionen verwendet werden, bis die Anwendung neu gestartet wird.
2. Geöffnete Dateien werden tatsächlich aus den Dateideskriptoren gelesen , nicht aus den Dateinamen, sodass der Dateiinhalt auch dann für die ausgeführten Anwendungen verfügbar bleibt, wenn sie verschoben, umbenannt oder gelöscht werden, bis die Sektoren überschrieben oder die Dateideskriptoren geschlossen werden.
3. Pakete, die neu geladen oder neu gestartet werden müssen, werden normalerweise vom Paketmanager ordnungsgemäß behandelt, wenn das Paket ordnungsgemäß entworfen wurde. Beispielsweise wird Debian bestimmte Dienste neu starten, wenn libc6 aktualisiert wird.

Wenn Sie Ihren Kernel nicht aktualisieren und ksplice nicht verwenden, müssen Programme oder Dienste möglicherweise neu gestartet werden, um die Vorteile eines Updates zu nutzen. Es ist jedoch selten erforderlich, ein System neu zu starten, um ein Update im Benutzerland durchzuführen, obwohl es auf Desktops gelegentlich einfacher ist, einzelne Dienste neu zu starten.

Siehe auch

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

Ja, was Sie beschrieben haben, ist möglich, aber die meiste Zeit, wenn die Datei im Paket enthalten ist, handelt es sich um eine Bibliothek oder eine andere Datei, die nur einmal gelesen wird (da sie sich nicht ändert, gibt es keinen Grund dafür) mehrmals lesen). Auch wenn die Datei langfristig benötigt wird, lässt die Anwendung wahrscheinlich das Datei-Handle geöffnet, wobei das geöffnete Datei-Handle die alte Version auch dann geöffnet hält, wenn es im tatsächlichen Dateisystem ersetzt wird.

In den meisten Fällen handelt es sich bei Daten, die während der Laufzeit des Prozesses mehrmals gelesen werden, um Benutzer- / Variablendaten. Dies würde sich während eines Paket-Upgrades nicht ändern. Da die Daten variabel sind, würde jeder Programmierer, der bei Verstand ist, sicherstellen, dass das Programm mit dem Wechsel von einem Lesevorgang zum nächsten umgehen kann.

Angenommen, "B" wurde auch im Dateisystem ersetzt. Jetzt muss "A" aus irgendeinem Grund wieder "B" lesen. Die Frage ist: Ist es möglich, dass "A" eine inkompatible Version von "B" findet und auf andere Weise abstürzt oder nicht funktioniert?

Dies ist möglich, aber in den meisten Fällen unwahrscheinlich. Wenn "B" eine Codebibliothek ist, wird die Originalversion normalerweise nicht geschlossen. "A" würde weiterhin die Originalversion von "B" verwenden. Wenn Sie nach dem Update "A" ausführen, wird die neue Version von "B" verwendet. Während des Updates besteht das Risiko, dass inkompatible Versionen geladen werden. Aufgrund der Art und Weise, wie Codebibliotheken geladen werden, sollte dies jedoch nur dann ein Problem sein, wenn "A" Funktionen benötigt, die in den geladenen Versionen von "B" nicht vorhanden sind.

Gute Codierungspraxis hält die Schnittstelle zu Funktionen gleich. Folglich spielt es keine Rolle, welche Version geladen ist, es sei denn, in der neueren Version wurden Fehler behoben.

Konfigurationsdateien sind etwas anders, werden jedoch normalerweise beim Start gelesen. In diesem Fall würde "A" nicht "B" lesen, es sei denn, ein erneutes Laden der Konfiguration wurde geändert. Auch hier wäre es eine schlechte Codierungspraxis, das Format oder die Bedeutung der Konfigurationsdatei zu ändern. Eine inkompatible Version der Konfigurationsdatei sollte einen anderen Namen haben, damit dies kein Problem verursacht.

Warum aktualisiert niemand seine Systeme durch einen Neustart mit einer Live-CD oder einem ähnlichen Verfahren?

Das Herunterfahren und Neustarten von einer anderen Version aus würde zu einem Serviceausfall führen. Für Server ist dies in der Regel nicht erwünscht. In jedem Fall ist der Paketmanager auf dem laufenden System über die installierte Software und Versionen informiert. Live-CDs enthalten eine eigene Liste der installierten Software, möglicherweise mit unterschiedlichen Versionen. Dies macht es schwierig, das laufende System zuverlässig von der Live-CD zu aktualisieren.

Live-CDs werden manchmal verwendet, wenn eine neue Version des Betriebssystems installiert wird. In diesem Fall wird normalerweise eine Neuinstallation des Betriebssystems durchgeführt. Dies kann die Anzahl der nicht verwendeten Dateien aus der vorherigen Version begrenzen, die beibehalten werden. Dies kann aufwändiger sein als ein Upgrade des Live-Systems. Wenn jedoch unterschiedliche Root-Partitionen verwendet werden, kann das Risiko eingeschränkt werden, dass ein nicht bootfähiges, teilweise aktualisiertes System hängen bleibt.

In einigen Fällen ist dies ein Problem:

• JDK-Upgrade während eine Java-VM ausgeführt wird: Ich habe myselv die gleiche Frage gestellt, die Sie gestellt haben - ich hatte einen laufenden Tomcat, der Java verwendet. Jetzt nach einem Patch-Update des JDK lief es noch ohne Probleme - so schien es.

Die Erklärung ist jetzt Cache-Speicher. OK - Ich habe ein Memory-Hog-Programm gestartet, um den gesamten verfügbaren Arbeitsspeicher zu nutzen - und dann ist Tomcat abgestürzt (nachdem ich auf die dort ausgeführte Anwendung zugegriffen habe).

• Kernel-Upgrade auf SuSE-Systemen: Unter SuSE werden der alte Kernel und seine Module direkt nach dem Patch-Upgrade des Kernels gelöscht. Wenn Sie dann etwas Neues verwenden möchten, für das ein Kernel-Modul erforderlich ist, das bisher nicht geladen wurde, schlägt der Dienst fehl.