Pourquoi la mise à jour d'un système Linux en cours d'exécution n'est pas problématique?

Cela fait des années que j'utilise des systèmes Linux au quotidien, et je n'ai jamais eu de problème majeur en mettant à jour un système lorsqu'il était en cours d'exécution, mais je me demande toujours pourquoi c'est possible.

Permettez-moi de vous donner un exemple.

Supposons qu'un programme "A" d'un certain package s'exécute sur un système. Ce programme, à un certain point, doit ouvrir un autre fichier ("B") du même paquet. Après cela, le programme "A" ferme "B" car il n'en a plus besoin. Supposons maintenant que je mette à jour les packages "A" et "B". "A" n'est pas directement affecté par ces opérations, du moins pour le moment, car il s'exécute en RAM et la mise à jour vient de remplacer "A" sur le disque dur. Supposons que "B" ait également été remplacé sur le système de fichiers. Maintenant "A" doit relire "B" pour une raison quelconque. La question est: est-il possible que "A" puisse trouver une version incompatible de "B" et planter ou mal fonctionner d'une autre manière?

Pourquoi personne ne met à jour ses systèmes en redémarrant avec un CD live ou une procédure similaire?

La mise à jour d'Userland est rarement un problème

Vous pouvez souvent mettre à jour des packages sur un système actif car:

1. Les bibliothèques partagées sont stockées en mémoire, et non lues sur le disque à chaque appel, les anciennes versions resteront donc en service jusqu'au redémarrage de l'application.
2. Les fichiers ouverts sont en fait lus à partir des descripteurs de fichiers , pas des noms de fichiers, de sorte que le contenu du fichier reste disponible pour les applications en cours d'exécution même lorsqu'il est déplacé / renommé / supprimé jusqu'à ce que les secteurs soient écrasés ou que les descripteurs de fichiers soient fermés.
3. Les packages qui nécessitent un rechargement ou un redémarrage sont généralement gérés correctement par le gestionnaire de packages si le package a été bien conçu. Par exemple, Debian redémarrera certains services à chaque mise à jour de libc6.

En règle générale, à moins que vous ne mettiez à jour votre noyau et que vous n'utilisez pas ksplice, les programmes ou services peuvent devoir être redémarrés pour profiter d'une mise à jour. Cependant, il est rarement nécessaire de redémarrer un système pour mettre à jour quoi que ce soit dans l'espace utilisateur, bien que sur les postes de travail, il soit parfois plus facile que de redémarrer des services individuels.

Voir également

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

Oui, ce que vous avez décrit est possible, mais la plupart du temps, si le fichier est inclus dans le package, ce sera une bibliothèque ou un autre fichier qui sera lu une seule fois (car il ne change pas, il n'y a aucune raison de lisez-le plusieurs fois). De plus, si le fichier est nécessaire à long terme, l'application laissera probablement le descripteur de fichier ouvert, dans lequel même s'il est remplacé sur le système de fichiers réel, le descripteur de fichier ouvert gardera l'ancienne version ouverte.

Dans la plupart des cas, toutes les données qui sont lues plusieurs fois au cours de la vie du processus sont des données utilisateur / variables, et cela ne changerait pas pendant la mise à niveau d'un package. De plus, comme les données sont variables, tout programmeur sensé devrait s'assurer que le programme peut gérer le passage d'une lecture à l'autre.

Supposons que "B" ait également été remplacé sur le système de fichiers. Maintenant, "A" doit relire "B" pour une raison quelconque. La question est: est-il possible que "A" puisse trouver une version incompatible de "B" et planter ou mal fonctionner d'une autre manière?

C'est possible, mais peu probable dans la plupart des cas. Si "B" est une bibliothèque de codes, la version d'origine ne sera généralement pas fermée. "A" continuerait d'utiliser la version originale de "B". Si vous exécutez "A" après la mise à jour, la nouvelle version de "B" sera utilisée. Pendant la mise à jour, il existe un risque que des versions incompatibles puissent être chargées. Cependant, en raison de la façon dont les bibliothèques de code sont chargées, cela ne devrait poser problème que si "A" a besoin de fonctionnalités non présentes dans les versions de "B" qu'il a chargées.

Les bonnes pratiques de codage permettent de maintenir l'interface aux mêmes fonctions. Par conséquent, peu importe la version chargée, sauf s'il y a eu des bogues corrigés dans la version la plus récente.

Les fichiers de configuration sont légèrement différents, mais sont généralement lus au démarrage. Dans ce cas, "A" ne lirait "B" que si un rechargement de la configuration était modifié. Encore une fois, ce serait une mauvaise pratique de codage de changer le format ou la signification du fichier de configuration. Une version incompatible du fichier de configuration doit avoir un nom différent, donc cela ne posera pas de problème.

Pourquoi personne ne met à jour ses systèmes en redémarrant avec un CD live ou une procédure similaire?

L'arrêt et le redémarrage d'une version différente entraîneraient une panne de service. Pour les serveurs, cela n'est généralement pas souhaité. Dans tous les cas, le gestionnaire de packages sur le système en cours d'exécution connaît les logiciels et les versions qu'il a installés. Les CD Live ont leur propre liste de logiciels installés, éventuellement avec des versions différentes. Cela rend difficile la mise à niveau fiable du système en cours d'exécution à partir du CD live.

Les CD Live sont parfois utilisés lors de l'installation d'une nouvelle version de O / S. Dans ce cas, l'installation propre du système d'exploitation est généralement effectuée. Cela peut limiter la quantité de fichiers inutilisés de la version précédente conservés. Cela peut demander plus d'efforts que la mise à niveau du système en direct. Cependant, si différentes partitions racine sont utilisées, cela peut limiter le risque d'être bloqué avec un système non amorçable partiellement mis à jour.

Il y a des cas où c'est un problème:

• Mise à niveau de JDK pendant qu'une java-VM est en cours d'exécution: J'ai posé à moi-même la même question que vous aviez - j'avais un tomcat en cours d'exécution qui utilise java. Maintenant, après une mise à jour de correctif du JDK, il fonctionnait toujours sans problème - il semblait donc.

Maintenant, l'explication est la mémoire cache. OK - j'ai démarré un programme de mémoire de porc pour utiliser toute la mémoire RAM disponible - puis Tomcat s'est écrasé (après avoir accédé à l'application qui s'y exécutait).

• Mise à niveau du noyau sur les systèmes SuSE: Sur SuSE, l'ancien noyau et ses modules sont supprimés juste après la mise à niveau des correctifs du noyau. Si vous souhaitez ensuite utiliser quelque chose de nouveau, qui nécessite un module noyau, qui n'a pas été chargé jusqu'à présent, le service échouera.