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

25

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?

Francesco Turco
la source
J'ai tendance à préférer éviter de telles mises à jour, non pas à cause des mécanismes de mise à jour (cela peut être fait très bien), mais plutôt à cause d'une préférence pour tester mes applications et ma configuration par rapport aux changements, d'abord. Ensuite, j'aurais un système distinct maintenant mis à jour pour basculer. Mais à part cela, la mise à jour dans l'espace utilisateur n'est généralement pas un problème, et pour les petits correctifs ou les correctifs de sécurité, je le ferais juste.
Skaperen

Réponses:

23

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

CodeGnome
la source
Mais que se passera-t-il si vous avez besoin de toute la mémoire cache? Dans ce cas, les bibliothèques de partage devront être à nouveau chargées à partir du disque ...
Nils
3
En fait, la description de # 1 n'était pas si claire. L'ancien contenu du fichier de bibliothèque reste sous un inode séparé (original), même si tous les noms qui y sont liés ont disparu, tant que le processus est ouvert ou que son contenu est mappé, les données restent distinctes (et le système de fichiers ne peut pas être remonté r / o jusqu'à ce que la dissociation du fichier soit terminée). Le processus qui a mappé le fichier d'origine a toujours des mappages de mémoire au contenu d'origine.
Skaperen
@Nils Je ne suis pas un expert, mais si vous manquez de cache, ne serait-il pas écrit pour permuter et relire à partir de là? Si celui-ci était plein, un processus serait probablement bloqué avant de pouvoir retirer de la mémoire à un autre processus qui l'utilise déjà.
Joe
@Joe no - swap is ram, too. Skaperen décrit ce qui se passe: le descripteur de fichier est maintenu intact. Donc, fondamentalement, le programme a un problème avec l'ancienne bibliothèque (disparue), qui ne sera pas supprimée jusqu'à ce que cette poignée soit à nouveau libre - tout cela au niveau du système de fichiers - pas au niveau de la RAM.
Nils
4

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.

Patrick
la source
Le fichier peut toujours être relu en tant que «stockage de sauvegarde» si le mappage de celui-ci n'a pas modifié la mémoire (ce qui autrement déplacerait le stockage de stockage pour permuter si disponible), et la copie en mémoire est supprimée en raison d'une autre pression de la demande à utiliser Mémoire. Mais ce n'est pas un problème car le fichier d'origine est toujours ouvert ou mappé. La bibliothèque de remplacement est un fichier nouveau et différent que l'ancien processus n'a pas ouvert.
Skaperen
1
@ Skaperen Je suppose que vous parlez de fichiers mappés en mémoire. Ce ne sont pas des problèmes lors de la mise à niveau des packages. Tous les gestionnaires de packages créent de nouveaux fichiers pour remplacer les anciens au lieu de les écraser. En fait, c'est la seule façon de le faire car un exécutable en cours d'exécution ne peut pas être modifié, il ne peut être dissocié.
Patrick
4

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.

BillThor
la source
0

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.
Nils
la source
2
Des sons comme certains morceaux de Tomcat ont été redémarrés, ou des bibliothèques dynamiques ont été utilisées en dessous du niveau Java (par exemple dlopen () et autres) qui pourraient se retrouver avec un mélange d'API en direct.
Skaperen
@Skaperen même lorsque vous utilisez des bibliothèques partagées - si elles se ferment après utilisation, tout programme devrait avoir des problèmes si le cache est rare ...
Nils
1
Un descripteur de fichier ouvert a le même pouvoir de conserver les données sur disque que le nom du fichier dans un répertoire. L'inode d'origine ne sera pas supprimé tant qu'il y aura un lien dur sur le disque ou un descripteur de fichier ouvert. Le cache n'a rien à voir avec ça. Maintenant, certains programmes ferment leurs descripteurs de fichiers lorsqu'ils ne les utilisent pas et cela peut laisser les données disparaître.
dmckee
@dmckee C'est vrai. Nous nous rapprochons du cœur. Alors, qu'est-ce qui est normal pour un programme "normal": ouvrir la bibliothèque et la garder ouverte, ou charger la bibliothèque et la fermer ensuite?
Nils