bonjour à tous,
quand je fais sur mon terminal apt update et apt upgrade, le programme peut mettre a jour la libc. Je me pose donc des questions sur ce qui se passe sur ma machine, car le noyau verrouille les binaires ELF qui sont en running. Donc le noyau interdit de pouvoir réécrire sur ces fichiers binaires. Or si je fais un upgrade je vais devoir supprimer les versions précédentes et mettre la nouvelle version, donc qu'est ce se passe ? il est impossible de mettre à jour la libc car elle est toujours utilisé ?
merci d'avance pour votre aide
# apt roulaize
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 12 avril 2019 à 12:33.
C'est géré, bien entendu:
https://www.debian.org/doc/manuals/debian-faq/ch-uptodate.fr.html
(Point 9.2)
La gelée de coings est une chose à ne pas avaler de travers.
# Es-tu sûr de tes sources ?
Posté par chimrod (site web personnel) . Évalué à 4.
Es-tu sûr de ton postulat ? De mon côté, j'ai ça dans la FAQ de ma distribution :
# Cela ne se passe pas bien
Posté par Renault (site web personnel) . Évalué à 2.
Il est tout à fait possible de mettre à jour un fichier binaire du système à chaud. C'est ce que font les distributions usuellement. En fait cela ne pose pas de problèmes immédiats car comme le fichier est chargé en mémoire, le changer sur le disque n'a pas d'impact direct.
Cependant, ce n'est pas une étape indolore et sans risque. En effet, en mettant à jour à chaud, ton système peut être dans un état incohérent jusqu'au prochain redémarrage complet. Admettons par exemple que je mets à jour Firefox et une bibliothèque dont il dépend. Si je redémarre Firefox, le nouveau binaire de Firefox sera chargé en mémoire mais la bibliothèque pas forcément, car elle existe en mémoire et sans doute déjà utilisée. Du coup Firefox va faire des appels à cette bibliothèque qui peuvent agir bizarrement car il a été testé et compilé avec la nouvelle version.
C'est pourquoi il est recommandé de faire les mises à jour à froid (lors de l'allumage ou de l'extinction de l'ordinateur) comme le propose GNOME Logiciels par défaut ou comme fait Windows habituellement.
[^] # Re: Cela ne se passe pas bien
Posté par viviNeutron . Évalué à 2.
merci de ta réponse.
Il me semblait tout de meme que pour minimiser l'espace mémoire de la RAM le noyau ne chargeait pas forcément tout le binaire, cela permet notamment a ce que des binaires qui dépassent la taille de la RAM puissent etre tout de meme lancé. Et lors d'une faute de page le noyau pouvait récupérer la partie du binaire manquant et la charger en RAM. c'est pourquoi le noyau verrouille les binaires.
[^] # Re: Cela ne se passe pas bien
Posté par Zenitram (site web personnel) . Évalué à 1.
Pour rebondir sur le sujet (et comme l'entrée de forum est dans "linux.noyau"…) :
A noter qu'on sait mettre à jour un binaire en fonctionnement, genre le kernel.
ksplice, liveupdate…
Bref, tout est question de savoir ce qu'on veut et si ça a été développé pour être mettable à jour, et parfois on fait le nécessaire pour que ça se passe bien même pendant que ça tourne, pas que pour le prochain "load".
[^] # Re: Cela ne se passe pas bien
Posté par Cyril Brulebois (site web personnel) . Évalué à 2.
Est-ce que tu parles du mécanisme d'
overcommit? Auquel cas ça permet effectivement de réserver de la place qui n'est pas (nécessairement) disponible, notamment à coup demalloc. Je ne suis pas certain que ça concerne le chargement des binaires et des bibliothèques dont ils ont besoin…Debian Consultant @ DEBAMAX
[^] # Suppression (ou remplacement) d’un fichier ouvert
Posté par Arthur Accroc . Évalué à 4.
Lorsqu’un fichier ouvert en lecture ou écriture est supprimé, il est déréférencé du répertoire, mais il n’est pas réellement supprimé. Il est maintenu sur le système de fichiers (sa place n’est pas récupérée) jusqu’à ce qu’il soit fermé (ou à la limite que le programme qui le maintien ouvert se termine), et c’est à lui que continue d’accéder le programme qui l’a ouvert, quand bien même un nouveau fichier du même nom le remplacerait dans son répertoire.
Dans le cas d’une bibliothèque ou d’une ressource quelconque, c’est un comportement clairement souhaitable. Si on empêchait tout remplacement d’un fichier utilisé, ça rendrait les mises à jour difficiles. Si un fichier était changé par un autre pendant qu’il est utilisé, ça causerait des problèmes de stabilité.
Dans la plupart des cas, on n’a pas à se préoccuper de fonctionnement, mais c’est mieux quand même d’en être conscient pour certains cas particuliers.
Par exemple, si un log remplit la partition et qu’on se dit qu’on va le supprimer pour faire de la place, il continue d’exister tant qu’on a pas relancé le service qui écrit dedans.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Cela ne se passe pas bien
Posté par benoar . Évalué à 2. Dernière modification le 13 avril 2019 à 00:04.
Oui, il mappe les pages à la demande.
Ça n'est pas un « verrouillage » au sens filesystem du terme : il a une référence vers un inode dans le VFS qui sera toujours le même même si le fichier est remplacé ; ainsi, un « écrasement » lors d'une mise à jour ne le perturbera pas. Mais note que niveau VFS, c'est un unlink + creat (ou rename), donc un fichier différent qui est créé à sa place. Le fichier binaire original restera inchangé. On pourrait modifier l'exécutable « en live » également, le noyau ne l'interdit pas, si tu as encore une référence au descripteur du fichier mappé : ça ferait effectivement des trucs bizarre, bien qu'il faille également correctement jouer de l'invalidation du cache d'instruction pour obtenir un truc maîtrisé.
[^] # Re: Cela ne se passe pas bien
Posté par benoar . Évalué à 4.
Faux, le loader (ld) charge la version de la lib présente sur le FS au moment de l'exécution du programme (ou de l'exécution du dlopen pour ceux qui l'utilisent).
Si un autre programme lancé avant la MàJ tourne toujours, il utilise lui les anciennes version, même si elles ne référencent plus de fichier réellement existant sur le disque : le disque est toujours utilisé comme backing-store, mais avec des inodes dont les dernières références sont ces processus, mais plus aucun dossier ; le fichier « disparaîtra » quand les programmes seront terminés.
Je n'ai jamais entendu un tel argument, qui me semble saugrenu. La seule raison valable c'est d'être certain que tous les programmes qui tournent utilisent bien la dernière version, en cas de MàJ de sécurité surtout.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.