Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Quelques questions sur le fonctionnement d'APT

Deuchnord

Bonjour,

Je m'excuse au préalable si mon message est mal placé, je ne savais pas trop où le poster :-°

Je m'intéresse en fait actuellement au fonctionnement d'APT, et je me pose quelques questions à ce propos...
Les voici, à la volée :

Lorsque l'on effectue une mise à jour (par le biais du gestionnaire de mises à jour ou par le biais de apt-get) d'un logiciel en cours d'exécution, cela semble ne pas interférer avec le fonctionnement dudit logiciel. Pourtant, il y a si je ne me trompe pas remplacement de l'exécutable, donc possibilité de plantage du programme en cours d'exécution au moment de la mise à jour. Cela n'a pourtant pas lieu.
Pire : il arrive qu'une mise à jour d'APT ait lieu, et dans ce cas, il effectue sa propre mise à jour sans pour autant faire planter l'ensemble du programme de mise à jour. Par quel magie cela est-il possible ?
Sous Windows, lorsque la mise à jour implique la modification de fichiers système, le système de redémarrer. Cela semble ne pas être toujours vrai sous Linux (à part lorsqu'une nouvelle version du noyau est disponible, et encore l'ancienne version est toujours disponible). Comment sont effectuées les mises à jours des fichiers système pour permettre que le système ne doive pas être redémarré ?
Et question stupide : dans ce cas, pourquoi Microsoft ne s'est-il pas inspiré d'APT (ou de RPM ou d'un autre gestionnaire de paquet Linux) pour améliorer son système de mise à jour ?
Cette question n'est pas un appel au troll, juste une question d'un ex-Windowsien à la recherche de réponses...

Merci pour vos réponse 🙂

Joss17

Quand un programme est lancé, tu peux modifier le fichier exécutable mais le programme ne bougera pas tant qu'il n'est pas fermé. Il y à un mécanisme de chargement qui permet cela.
C'est valable pour tout les programmes, donc tu peux modifier tout ton système (y compris apt-get lui-même), ça ne sera pris en compte que lorsque tu arrête et redémarre les programmes.

a+

Deuchnord

Donc en fait la totalité du programme est stocké dans la mémoire vive, c'est ça ? Cela ne poserait-il pas un problème pour les programmes les plus lourds ? :-°
À moins que le programme soit copié dans un dossier temporaire pour garantir son fonctionnement à tout moment pendant l'exécution ?
Merci pour la réponse 🙂

ssdg

Pas forcément. Le nouvel exécutable se situe à un endroit A du disque et l'ancien à un endroit B. L'endroit B n'est plus accessible aux nouveaux arrivants (il n'est plus dans la "table des matières") mais ceux qui ont déjà leur emplacement continuent d'accéder à l'ancienne version.

(par contre, s'ils "ferment" l'accès, ils retomberont sur le nouveau fichier, et pourront tomber sur des incohérences)

tiramiseb

Salut,

1. Je confirme l'explication de ssdg. Ton exécutable actuel est placé quelque part sur le disque. Lorsque tu remplaces le fichier par une nouvelle version, ça stocke les données ailleurs sur le disque (ça n'écrase pas les données du fichier courant) et ça change la référence dans cette "table des matières" (ce sont les inodes). Les anciennes données sont, elles, toujours là... tant que le fichier concerné reste ouvert.
Sous Windows par contre, ce fonctionnement n'est pas possible : on ne peut pas garder ouvert un fichier qui n'est plus référencé.

2. Une mise à jour par APT induit un redémarrage des exécutables concernés, un par un, si nécessaire. Par exemple, si le serveur web Apache est mis à jour, alors après mise à jour Apache est redémarré. Cela grâce au fait que l'instance précédente peut toujours être utilisée, même si elle n'est pas référencée. Sous Windows, vu qu'on ne peut pas modifier un fichier pendant qu'il est ouvert, j'imagine que lors de la mise à jour le système stocke les données dans un espace temporaire et il les déplace au moment du redémarrage pour écraser le fichier précédent.

Du coup, réponse à ta question pas stupide : Microsoft ne peut pas s'inspirer du fonctionnement des systèmes de fichiers UNIX parce que NTFS est un peu pourrave (ou alors c'est sa gestion des accès aux fichiers qui est pourrave, auquel cas ils pourraient faire en effet mieux...) 🙂

maxpoulin64

Les exécutables sont toujours chargés entièrement en RAM. Si on faisait autrement, il faudrait sans cesse aller chercher les données manquantes sur le disque dur et ça serait vraiment très (trop) lent. Ça serait presque aussi pire que de faire tourner le system entier sur le swap. C'est aussi ça qui explique que l'on peut supprimer la commande rm en utilisant rm: elle est entièrement chargée en mémoire avant de s'exécuter. Je crois qu'il existe un moyen de spécifier des zones de données qui ne sont pas à être chargées en mémoire, permettant de lancer de très gros exécutables sans devoir tout mettre en RAM. Ça c'est quelque chose que Windows fait pour le moins, pas mal certain que ça se fait sur Linux aussi mais faudrait que je me documente sur le linker et le format ELF.

Après, sur GNU/Linux, les exécutables sont plutôt petits:

~ % ls -ASlh /usr/bin/ | head -n 20
total 359M
-rwxr-xr-x 1 root root  60M  9 jui 21:21 pcsx2*
-rwxr-xr-x 1 root root  14M 11 mai 11:57 clementine*
-rwxr-xr-x 1 root root  11M  2 aoû  2012 cgc*
-rwxr-xr-x 1 root root 9,8M 27 avr 20:24 gs*
-rwxr-xr-x 1 root root 8,8M 14 jun 08:22 godoc*
-rwxr-xr-x 1 root root 7,5M 14 jun 08:22 go*
-rwxr-xr-x 1 root root 5,5M 10 jui 11:39 pyrogenesis*
-rwxr-xr-x 1 root root 5,4M 28 avr 09:49 xlinpack_xeon64*
-rwxr-xr-x 1 root root 5,4M 23 jun 17:17 gimp-2.8*
-rwxr-xr-x 1 root root 5,2M  4 jui 13:57 smbtorture*
-rwxr-xr-x 1 root root 5,0M 27 avr 02:24 gdb*
-rwxr-xr-x 1 root root 4,7M  4 jui 03:12 ctest*
-rwxr-xr-x 1 root root 4,4M  1 jun 07:37 dolphin-emu*
-rwxr-xr-x 1 root root 4,2M  5 jui 13:54 go-mtpfs*
-rwxr-xr-x 1 root root 3,9M  4 jui 03:12 cmake-gui*
-rwxr-xr-x 1 root root 3,8M  4 jui 03:12 cpack*
-rwxr-xr-x 1 root root 3,8M  2 avr 17:53 js17*
-rwxr-xr-x 1 root root 3,6M  4 jui 03:12 ccmake*
-rwxr-xr-x 1 root root 3,6M  4 jui 03:12 cmake*

Comme tu peux le voir, les exécutables les plus gourmands font 60 Mo (un émulateur) suivi d'un autre de 10 Mo, pour un total de 359 Mo pour l'ensemble des exécutables sur mon PC.

Comment es-ce possible d'utiliser aussi peu d'espace? Tout est organisé en librairies. Les applications GTK link a la librairie GTK, qui n'est chargée qu'une seule fois. Pareil pour Qt, et pareil pour toutes les librairies. Tu peux obtenir la liste des dépendances avec dpkg, je crois. D'ailleurs, les librairies non plus ne sont pas très gourmandes:

~ % ls -ASlh /usr/lib/ | head -n 11
total 598M
-rwxr-xr-x  1 root root   36M 27 jun 15:12 libnvidia-glcore.so.319.32*
-rwxr-xr-x  1 root root   27M 24 mai 14:04 libLLVM-3.2svn.so*
-rwxr-xr-x  1 root root   26M 14 jun 18:29 libwebkitgtk-1.0.so.0.17.5*
-rwxr-xr-x  1 root root   22M 24 mai 15:43 libicudata.so.51.2*
-rw-r--r--  1 root root   20M  2 aoû  2012 libCg.so
-rw-r--r--  1 root root   19M  5 mar 12:28 libcryptopp.a
-rwxr-xr-x  1 root root   11M  2 jui 06:19 libQtGui.so.4.8.5*
-rwxr-xr-x  1 root root   11M 27 avr 20:24 libgs.so.9.07*
-rwxr-xr-x  1 root root   11M 27 jun 15:12 libcuda.so.319.32*
-r-xr-xr-x  1 root root  8,1M 21 mai 11:50 libpython3.3m.so.1.0*

Et enfin, finalement, sur GNU/Linux les applications stockent toutes leurs données dans des fichiers séparés, souvent dans /usr/share. Par exemple, les icones sont toutes dans /usr/share/icons, les plugins d'applications dans /usr/lib/(application)/ (ex: /usr/lib/mupen64plus/), les fichiers de l'application dans /usr/share/(applicatuin) (ex: /usr/share/skype/)

/usr/share/skype % tree .
.
├── avatars
│   ├── Angel Skype.png
│   ├── Architect Skype.png
│   ├── Beach Skype.png
│   ├── Behind Skype.png
│   ├── Business Skype.png
│   ├── Call Me.png
│   ├── Call Me Sweetheart.png
│   ├── Carnaval Skype.png
│   ├── Chic Skype.png
│   ├── Christmas Skype.png
│   ├── College Skype.png
│   ├── Desert Skype.png
│   ├── Designer Skype.png
│   ├── Devil Skype.png
│   ├── DIY Skype.png
│   ├── DJ Skype.png
│   ├── Earbud Skype.png
│   ├── Empire Skype.png
│   ├── Fax Skype.png
│   ├── Geisha Skype.png
│   ├── Hula Skype.png
│   ├── Make Skype Not War.png
│   ├── Metal Skype.png
│   ├── Ninja Skype.png
│   ├── Party Skype.png
│   ├── Pop Skype.png
│   ├── Rice Skype.png
│   ├── Skypahontas.png
│   ├── Skype 502.png
│   ├── Skype-ahoy.png
│   ├── Skype Aid.png
│   ├── Skype-a-Manger.png
│   ├── Skype Artiste.png
│   ├── Skype Beauty.png
│   ├── Skype Bling.png
│   ├── Skype Boarder.png
│   ├── Skype Brrr... .png
│   ├── Skype Candy.png
│   ├── Skype Cola.png
│   ├── Skype Cool Shades.png
│   ├── Skype Extreme.png
│   ├── Skype Goaaaaal.png
│   ├── Skype Headset.png
│   ├── Skype in a Bag.png
│   ├── Skype-in-one.png
│   ├── Skype Jah.png
│   ├── Skype Jyve.png
│   ├── Skype.png
│   ├── Skypers of the Caribbean.png
│   ├── Skype Safety.png
│   ├── Skype San.png
│   ├── Skype Shorty.png
│   ├── Skype Smiley.png
│   ├── Skype Time.png
│   ├── Star Skype.png
│   ├── Sushi Skype.png
│   ├── The Skypeness.png
│   ├── Travel Skype.png
│   ├── Wetsuit Skype.png
│   └── Yin Yang Skype.png
├── lang
│   ├── skype_bg.qm
│   ├── skype_bg.ts
│   ├── skype_cs.qm
│   ├── skype_cs.ts
│   ├── skype_de.qm
│   ├── skype_de.ts
│   ├── skype_en.qm
│   ├── skype_en.ts
│   ├── skype_es.qm
│   ├── skype_es.ts
│   ├── skype_et.qm
│   ├── skype_et.ts
│   ├── skype_fr.qm
│   ├── skype_fr.ts
│   ├── skype_it.qm
│   ├── skype_it.ts
│   ├── skype_ja.qm
│   ├── skype_ja.ts
│   ├── skype_ko.qm
│   ├── skype_ko.ts
│   ├── skype_lt.qm
│   ├── skype_lt.ts
│   ├── skype_lv.qm
│   ├── skype_lv.ts
│   ├── skype_no.qm
│   ├── skype_no.ts
│   ├── skype_pl.qm
│   ├── skype_pl.ts
│   ├── skype_pt_br.qm
│   ├── skype_pt_br.ts
│   ├── skype_pt_pt.qm
│   ├── skype_pt_pt.ts
│   ├── skype_ro.qm
│   ├── skype_ro.ts
│   ├── skype_ru.qm
│   ├── skype_ru.ts
│   ├── skype_th.qm
│   ├── skype_th.ts
│   ├── skype_tr.qm
│   ├── skype_tr.ts
│   ├── skype_uk.qm
│   ├── skype_uk.ts
│   ├── skype_zh_s.qm
│   ├── skype_zh_s.ts
│   ├── skype_zh_t.qm
│   └── skype_zh_t.ts
└── sounds
    ├── CallBusy.wav
    ├── CallConnecting.wav
    ├── CallFailed.wav
    ├── CallHangup.wav
    ├── CallHold.wav
    ├── CallRemoteHangup.wav
    ├── CallResume.wav
    ├── CallRingingIn.wav
    ├── CallRingingOut.wav
    ├── ChatIncomingInitial.wav
    ├── ChatIncoming.wav
    ├── ChatOutgoing.wav
    ├── ContactAdded.wav
    ├── ContactAuthRequest.wav
    ├── ContactOffline.wav
    ├── ContactOnline.wav
    ├── SkypeLogin.wav
    ├── SkypeLogout.wav
    ├── TransferComplete.wav
    ├── TransferFailed.wav
    ├── TransferRequest.wav
    └── VoicemailReceived.wav

3 directories, 128 files

BREF: Les exécutables sont chargés entièrement en mémoire, et tous les fichiers ressources sont séparés dans de nombreux fichiers séparés, donc l'application en cours d'exécution est très peu affectée. Lors d'une mise à jours, elle prend effet lorsque la librairie ou l'application est redémarrée (par exemple, en fermant toutes les applications Qt, la prochaine application Qt qui sera ouverte utiisera la version mise à jours). C'est pareil pour tous les composents, même ceux plus important comme le display manager, X, NetworkManager et autres. En plus de cela, APT redémarre automatiquement certains services lorsqu'ils sont mis à jours, tel que déjà mentionné. Seul le noyau nécessite un redémarrage complet pour être mis à jours (et il est possible, pour les machines nécessitant zéro downtime, d'utiliser des outils comme ksplice pour mettre à jours le noyau en place directement en mémoire).

En ce qui concerne Windows, beaucoup de programmes incluant ceux de Microsoft font redémarrer inutilement, juste pour être certain que tout est redémarré, pour être certain que certains logiciels ne tournent plus en arrière plan et autre. Certains composents sont également beaucoup plus étroitement liés entre eux, ce qui nécessite de redémarrer plusieurs choses. Mais dans le doute, ils préfèrent faire un redémarrage complet au cas où ça serait foireux. Tu peux en faire le test, installer un gros logiciel, refuser de redémarrer, tuer les services si nécessaire et démarrer l'application. Magie! Ça fonctionne parfaitement même sans redémarrer, même pour les drivers! C'est juste moins compliqué pour l'utilisateur lamda de simplement redémarrer le PC et tout fonctionne du premier coup, que de l'envoyer dans une longue procédure lui expliquant quoi faire pour toutes les conneries qui peuvent arriver et qui font que le logiciel plante au démarrage.

temp000

Le secret est là (cf ssdg et tiramiseb) : http://www.google.fr/url?sa=t&rct=j&q=inodes&source=web&cd=4&cad=rja&ved=0CEMQFjAD&url=http%3A%2F%2Fwww.dil.univ-mrs.fr%2F~tichit%2FTeaching%2FCurrent%2Funix%2Fcours%2F5.Inodes.Liens.pdf&ei=PafpUfeLNuPe4QSX84GIAg&usg=AFQjCNFiPuiIsEva_MKfE9z5D8w2g6YXdA
Et il y a un petit exercice à la fin, qui permet de se rendre compte par soi-même...

tiramiseb

maxpoulin64: Désolé, c'est un joli long message que tu as écrit, mais non, ton explication n'est pas juste.

Les exécutables et les bibliothèques sont partiellement chargés en mémoire, mais ce n'est pas vrai pour l'ensemble du fichier exécutable (ou autres).
C'est bel et bien parce que les fichiers restent ouverts qu'un exécutable peut être remplacé sans incidence sur son instance qui est en cours de fonctionnement, comme je l'ai expliqué en #5.

Tu peux voir la liste des fichiers ouverts par un exécutable avec la commande :

lsof -p <PID du programme>

Pas mal d'infos à ce propos avec la manpage de elf :

man elf

par exemple, en fermant toutes les applications Qt, la prochaine application Qt qui sera ouverte utiisera la version mise à jours

Je n'en suis pas persuadé. Je pense que, si tu mets Qt à jour, alors un programme lancé après la mise à jour utilisera la bibliothèque à jour.

Deuchnord

Merci pour vos réponses 🙂

Je pensais en fait que le mécanisme était plus compliqué que cela (en fait ce que je m'imaginais est tellement compliqué qu'il serait impossible de l'expliquer clairement, moi-même je m'y perdrais :o )

tiramiseb

Eh bien non, tout est extrêmement simple !
C'est le principe KISS : Keep It Simple, Stupid.

Ce qui fait la complexité de ces systèmes, ce n'est pas une quelconque complication : c'est l'imbrication d'un ensemble de choses simples.

BrunoGey

Deuchnord a écrit.........................
À moins que le programme soit copié dans un dossier temporaire pour garantir son fonctionnement à tout moment pendant l'exécution ?
Merci pour la réponse 🙂

Bonjour Deuchnord

En mémoire centrale oui exactement ...........et si nécessaire en swap = partition dédiée à cela dans le disque dur.

Avec Ubuntu...........tous les Linux je pense, tu peut régler un paramètre qui s'appelle " swapiness ", et qui dit à partir de combien de ram restante, faut il stocker dans la swap.

j'ai réglé le mien à 10%, ( swapiness = 10 ), ainsi mon système est censé swapper lorsqu'il ne restera que 10% de ram dispo; Sur mes 4go embarqués, il va donc me rester au mini, 400go ( 10% de 4go ), de dispo.
Mon système fonctionne en ram sur 3.6go, pour une bonne fluidité.

edit : lien dans le forum sur une explication claire et détaillée swapiness :

http://forum.ubuntu-fr.org/viewtopic.php?pid=7808401

cdt

bruno

tiramiseb

BrunoGey a écritEn mémoire centrale oui exactement ...........et si nécessaire en swap = partition dédiée à cela dans le disque dur.

As-tu lu mes réponses #5 et #8 ?

Bien qu'une partie de l'exécutable et des bibliothèques est stockée en RAM, ce n'est pas cela qui permet de faire ce genre de modifications alors même que les programmes sont en fonctionnement ; c'est bel et bien le fait que les fichiers restent ouverts sur leurs "précédents" descripteurs.

The Uploader

tiramiseb a écritEh bien non, tout est extrêmement simple !
C'est le principe KISS : Keep It Simple, Stupid.

Ce qui fait la complexité de ces systèmes, ce n'est pas une quelconque complication : c'est l'imbrication d'un ensemble de choses simples.

Y'a plus KISS que Ubuntu. :p

BrunoGey

tiramiseb a écrit
BrunoGey a écritEn mémoire centrale oui exactement ...........et si nécessaire en swap = partition dédiée à cela dans le disque dur.
As-tu lu mes réponses #5 et #8 ?

Bien qu'une partie de l'exécutable et des bibliothèques est stockée en RAM, ce n'est pas cela qui permet de faire ce genre de modifications alors même que les programmes sont en fonctionnement ; c'est bel et bien le fait que les fichiers restent ouverts sur leurs "précédents" descripteurs.

@tiramiseb

bon d'acc ttes mes excuses, je n'ai pas lu en détail.

désolé

cdt

bruno

maxpoulin64

@tiramiseb Parfait, j'en reste corrigé alors. J'avais lu l'inverse il y a un moment, le reste c'est des infos rassemblées ensemble, je me doutais que j'étais pas à 100% dessus.

tiramiseb

maxpoulin64: cela dit, une grosse part de chaque exécutable est chargée en mémoire, tu as raison. Mais ce n'est juste pas cela qui garantit que ça fonctionne après modification du fichier :-)