Forum Linux.noyau que ce passe t'il quand on fait des mises à jour sur un programme qui en cours d'exécution

Posté par . Licence CC by-sa.
Tags : aucun
2
12
avr.
2019

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 (page perso) . Évalué à 4. Dernière modification le 12/04/19 à 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 (page perso) . Évalué à 4.

    le noyau verrouille les binaires ELF qui sont en running

    Es-tu sûr de ton postulat ? De mon côté, j'ai ça dans la FAQ de ma distribution :

    Le noyau (et le système de fichiers) dans les systèmes Debian GNU/Linux permet le remplacement de fichiers même lorsqu'ils sont utilisés.

  • # Cela ne se passe pas bien

    Posté par (page perso) . É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 . É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 (page perso) . Évalué à 1.

        Pour rebondir sur le sujet (et comme l'entrée de forum est dans "linux.noyau"…) :

        car le noyau verrouille les binaires ELF qui sont en running.

        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 (page perso) . É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 de malloc. 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 . É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.

        ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

      • [^] # Re: Cela ne se passe pas bien

        Posté par . Évalué à 2. Dernière modification le 13/04/19 à 00:04.

        le noyau ne chargeait pas forcément tout le binaire

        Oui, il mappe les pages à la demande.

        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.

        Ç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 . Évalué à 4.

      Si je redémarre Firefox, le nouveau binaire de Firefox sera chargé en mémoire mais la bibliothèque pas forcément,

      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.

      C'est pourquoi il est recommandé de faire les mises à jour à froid

      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.