Bonjour,
Le mercredi 28 janvier 2015 à 14:43, Francois Lafont a écrit :Le 28/01/2015 14:34, Francois Lafont a écrit :echo "deb http://http.debian.net/debian/ squeeze-lts main contrib non-free" > /etc/apt/sources.list.d/squeeze-lts.list
apt-get update
apt-get upgrade
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
Si j'ai bien compris, si un daemon dépend d'une lib, il faut
redémarrer le-dit daemon après la mise à jour de la-dite lib.
Seulement j'ai cru comprendre que globalement, quasiment tous
les daemons (sous Debian) dépendent in fine de la glibc et
qu'au final un reboot est globalement nécessaire. Bref, j'ai
lu je ne sais plus où que l'idée selon laquelle seule la
màj du noyau nécessitait un reboot était inexacte et que le
reboot était également nécessaire pour la màj de la glic.
Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;)
Merci d'avance.
Loin de moi l'idée de me considérer comme tel…
Il y a justement une discussion à ce sujet en ce moment sur debian-security [1].
Tous les programmes qui utilisent de la bibliothèque mise à jour doivent être
redémarrés. On doit donc redémarrer les services qui l'utilisent.
Dans le cas de la libc, ça devient problématique car _tous_ les programmes du
système l'utilisent. Il faut donc redémarrer _tous_ les programmes actuellement
en fonctionnement.
Deux approches :
- tu les identifies un par un et tu les redémarres un par un (et tu ne fais
rien d'autre de ta journée);
- tu rebootes et c'est réglé en quelques minutes.
1: https://lists.debian.org/debian-security/2015/01/msg00035.html
Seb
Bonjour,
Le mercredi 28 janvier 2015 à 14:43, Francois Lafont a écrit :
Le 28/01/2015 14:34, Francois Lafont a écrit :
echo "deb http://http.debian.net/debian/ squeeze-lts main contrib non-free" > /etc/apt/sources.list.d/squeeze-lts.list
apt-get update
apt-get upgrade
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
Si j'ai bien compris, si un daemon dépend d'une lib, il faut
redémarrer le-dit daemon après la mise à jour de la-dite lib.
Seulement j'ai cru comprendre que globalement, quasiment tous
les daemons (sous Debian) dépendent in fine de la glibc et
qu'au final un reboot est globalement nécessaire. Bref, j'ai
lu je ne sais plus où que l'idée selon laquelle seule la
màj du noyau nécessitait un reboot était inexacte et que le
reboot était également nécessaire pour la màj de la glic.
Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;)
Merci d'avance.
Loin de moi l'idée de me considérer comme tel…
Il y a justement une discussion à ce sujet en ce moment sur debian-security [1].
Tous les programmes qui utilisent de la bibliothèque mise à jour doivent être
redémarrés. On doit donc redémarrer les services qui l'utilisent.
Dans le cas de la libc, ça devient problématique car _tous_ les programmes du
système l'utilisent. Il faut donc redémarrer _tous_ les programmes actuellement
en fonctionnement.
Deux approches :
- tu les identifies un par un et tu les redémarres un par un (et tu ne fais
rien d'autre de ta journée);
- tu rebootes et c'est réglé en quelques minutes.
1: https://lists.debian.org/debian-security/2015/01/msg00035.html
Seb
Bonjour,
Le mercredi 28 janvier 2015 à 14:43, Francois Lafont a écrit :Le 28/01/2015 14:34, Francois Lafont a écrit :echo "deb http://http.debian.net/debian/ squeeze-lts main contrib non-free" > /etc/apt/sources.list.d/squeeze-lts.list
apt-get update
apt-get upgrade
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
Si j'ai bien compris, si un daemon dépend d'une lib, il faut
redémarrer le-dit daemon après la mise à jour de la-dite lib.
Seulement j'ai cru comprendre que globalement, quasiment tous
les daemons (sous Debian) dépendent in fine de la glibc et
qu'au final un reboot est globalement nécessaire. Bref, j'ai
lu je ne sais plus où que l'idée selon laquelle seule la
màj du noyau nécessitait un reboot était inexacte et que le
reboot était également nécessaire pour la màj de la glic.
Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;)
Merci d'avance.
Loin de moi l'idée de me considérer comme tel…
Il y a justement une discussion à ce sujet en ce moment sur debian-security [1].
Tous les programmes qui utilisent de la bibliothèque mise à jour doivent être
redémarrés. On doit donc redémarrer les services qui l'utilisent.
Dans le cas de la libc, ça devient problématique car _tous_ les programmes du
système l'utilisent. Il faut donc redémarrer _tous_ les programmes actuellement
en fonctionnement.
Deux approches :
- tu les identifies un par un et tu les redémarres un par un (et tu ne fais
rien d'autre de ta journée);
- tu rebootes et c'est réglé en quelques minutes.
1: https://lists.debian.org/debian-security/2015/01/msg00035.html
Seb
Le 28/01/2015 20:59, Philippe Deleval a écrit :
>C'est une blague? A mon avis, tout programmeur utilisant la fonction de
>bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
>il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
>ct, n), le petit n fait la différence.
Et ceux qui créé la fonction strcpy sont des criminels qui devraient être
guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé
l'informatique...
Le 28/01/2015 20:59, Philippe Deleval a écrit :
>C'est une blague? A mon avis, tout programmeur utilisant la fonction de
>bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
>il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
>ct, n), le petit n fait la différence.
Et ceux qui créé la fonction strcpy sont des criminels qui devraient être
guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé
l'informatique...
Le 28/01/2015 20:59, Philippe Deleval a écrit :
>C'est une blague? A mon avis, tout programmeur utilisant la fonction de
>bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
>il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
>ct, n), le petit n fait la différence.
Et ceux qui créé la fonction strcpy sont des criminels qui devraient être
guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé
l'informatique...
C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il
travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n),
le petit n fait la différence.
C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il
travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n),
le petit n fait la différence.
C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il
travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n),
le petit n fait la différence.
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?
>>Ah, au fait, petite question. Après les commandes ci-dessus,
>>faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le
reboot ne me semble pas si important que cela (aie, je prend un
risque en disant cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un système
Linux sont protégés en écriture, petit rappel:
$ cat >> read_bloquant.c << FIN
# include <stdio.h>
int main (void)
{
read (0, NULL, sizeof(int));
/* En gros on exécute un appel système bloquant, on lit depuis
l'entrée standard, en général la console, NULL parce qu'on s'en fout
du résultat et le sizeof parce que ça fait plus cool qu'un 4 ou un 8
(et portable). Donc tant qu'on n'entre pas un caractère (dac, un
nombre (cela dit, c'est du C, c'est pareil pour "lui", chez moi il
en mange 4 donc int = 4 octets, moins si caractère en dehors ascii
et si console en UTF-8 par ex) et qu'on n'appuie pas sur Entrée le
programme attend */
exit (0);
}
FIN
Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
Donc on compile et on exécute:
$ gcc read_bloquant.c -o read_bloquant
$ ./read_bloquant
Ça y est, le processus attend.
Sur une autre console :
$ kate read_bloquant
(ou gedit, mousepad etc.)
Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
Et possible lorsque le programme n'est pas exécuté.
Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de
souci particulier, virtualbox (qui n'était pas en exécution) s'est
recompilé son module, 2-3 petits trucs et c'était bon.
Ce que j'en conclus, c'est que sur mon système la mise à jour n'a
remplacé aucun fichier en cours d'utilisation donc que le reboot
n'est peut-être pas indispensable.
Toutefois, juste pour être sûr et si j'étais admin je viderais tout
ce qui est buffer/cache avant la mise à jour et également après tant
qu'à faire:
# echo 3 > /proc/sys/vm/drop_caches
Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram),
je tuerais quelque processus après avoir exécuté:
# echo 0 > /proc/sys/vm/swappiness
Attention tout de même à ne pas exécuter cela sur un pc avec très
peu de mémoire mais de toute façon je suis même pas sûr que cette
dernière ligne aurait de l'effet dans ce cas.
Une dernière chose:
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir
entre autres grâce à strace que c'est
/lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est appelé chez moi),
aucun problème tant que le programme utilise un cache bien mis à
jour (ce qui est normalement le cas mais c'est t'on jamais d'où les
2 dernières commandes).
Si c'est statique (avec la libc ce doit être rare voire inexistant,
j'ai pas vérifié), alors là un reboot n'y fera rien, il faudra
recompiler le paquet, c'est d'ailleurs un des principaux désavantage
des librairies statiques (avec la quantité d'espace mémoire
utilisée, l'avantage étant un programme très légèrement plus
rapide).
Voilà pour mes petites réflexion, s'il y a des erreurs de logique
merci de me corriger.
Cordialement/Bises...
--
mrr
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/54ca32ea$0$3190$
>>Ah, au fait, petite question. Après les commandes ci-dessus,
>>faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le
reboot ne me semble pas si important que cela (aie, je prend un
risque en disant cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un système
Linux sont protégés en écriture, petit rappel:
$ cat >> read_bloquant.c << FIN
# include <stdio.h>
int main (void)
{
read (0, NULL, sizeof(int));
/* En gros on exécute un appel système bloquant, on lit depuis
l'entrée standard, en général la console, NULL parce qu'on s'en fout
du résultat et le sizeof parce que ça fait plus cool qu'un 4 ou un 8
(et portable). Donc tant qu'on n'entre pas un caractère (dac, un
nombre (cela dit, c'est du C, c'est pareil pour "lui", chez moi il
en mange 4 donc int = 4 octets, moins si caractère en dehors ascii
et si console en UTF-8 par ex) et qu'on n'appuie pas sur Entrée le
programme attend */
exit (0);
}
FIN
Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
Donc on compile et on exécute:
$ gcc read_bloquant.c -o read_bloquant
$ ./read_bloquant
Ça y est, le processus attend.
Sur une autre console :
$ kate read_bloquant
(ou gedit, mousepad etc.)
Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
Et possible lorsque le programme n'est pas exécuté.
Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de
souci particulier, virtualbox (qui n'était pas en exécution) s'est
recompilé son module, 2-3 petits trucs et c'était bon.
Ce que j'en conclus, c'est que sur mon système la mise à jour n'a
remplacé aucun fichier en cours d'utilisation donc que le reboot
n'est peut-être pas indispensable.
Toutefois, juste pour être sûr et si j'étais admin je viderais tout
ce qui est buffer/cache avant la mise à jour et également après tant
qu'à faire:
# echo 3 > /proc/sys/vm/drop_caches
Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram),
je tuerais quelque processus après avoir exécuté:
# echo 0 > /proc/sys/vm/swappiness
Attention tout de même à ne pas exécuter cela sur un pc avec très
peu de mémoire mais de toute façon je suis même pas sûr que cette
dernière ligne aurait de l'effet dans ce cas.
Une dernière chose:
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir
entre autres grâce à strace que c'est
/lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est appelé chez moi),
aucun problème tant que le programme utilise un cache bien mis à
jour (ce qui est normalement le cas mais c'est t'on jamais d'où les
2 dernières commandes).
Si c'est statique (avec la libc ce doit être rare voire inexistant,
j'ai pas vérifié), alors là un reboot n'y fera rien, il faudra
recompiler le paquet, c'est d'ailleurs un des principaux désavantage
des librairies statiques (avec la quantité d'espace mémoire
utilisée, l'avantage étant un programme très légèrement plus
rapide).
Voilà pour mes petites réflexion, s'il y a des erreurs de logique
merci de me corriger.
Cordialement/Bises...
--
mrr
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/54ca32ea$0$3190$426a74cc@news.free.fr
>>Ah, au fait, petite question. Après les commandes ci-dessus,
>>faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le
reboot ne me semble pas si important que cela (aie, je prend un
risque en disant cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un système
Linux sont protégés en écriture, petit rappel:
$ cat >> read_bloquant.c << FIN
# include <stdio.h>
int main (void)
{
read (0, NULL, sizeof(int));
/* En gros on exécute un appel système bloquant, on lit depuis
l'entrée standard, en général la console, NULL parce qu'on s'en fout
du résultat et le sizeof parce que ça fait plus cool qu'un 4 ou un 8
(et portable). Donc tant qu'on n'entre pas un caractère (dac, un
nombre (cela dit, c'est du C, c'est pareil pour "lui", chez moi il
en mange 4 donc int = 4 octets, moins si caractère en dehors ascii
et si console en UTF-8 par ex) et qu'on n'appuie pas sur Entrée le
programme attend */
exit (0);
}
FIN
Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
Donc on compile et on exécute:
$ gcc read_bloquant.c -o read_bloquant
$ ./read_bloquant
Ça y est, le processus attend.
Sur une autre console :
$ kate read_bloquant
(ou gedit, mousepad etc.)
Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
Et possible lorsque le programme n'est pas exécuté.
Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de
souci particulier, virtualbox (qui n'était pas en exécution) s'est
recompilé son module, 2-3 petits trucs et c'était bon.
Ce que j'en conclus, c'est que sur mon système la mise à jour n'a
remplacé aucun fichier en cours d'utilisation donc que le reboot
n'est peut-être pas indispensable.
Toutefois, juste pour être sûr et si j'étais admin je viderais tout
ce qui est buffer/cache avant la mise à jour et également après tant
qu'à faire:
# echo 3 > /proc/sys/vm/drop_caches
Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram),
je tuerais quelque processus après avoir exécuté:
# echo 0 > /proc/sys/vm/swappiness
Attention tout de même à ne pas exécuter cela sur un pc avec très
peu de mémoire mais de toute façon je suis même pas sûr que cette
dernière ligne aurait de l'effet dans ce cas.
Une dernière chose:
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir
entre autres grâce à strace que c'est
/lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est appelé chez moi),
aucun problème tant que le programme utilise un cache bien mis à
jour (ce qui est normalement le cas mais c'est t'on jamais d'où les
2 dernières commandes).
Si c'est statique (avec la libc ce doit être rare voire inexistant,
j'ai pas vérifié), alors là un reboot n'y fera rien, il faudra
recompiler le paquet, c'est d'ailleurs un des principaux désavantage
des librairies statiques (avec la quantité d'espace mémoire
utilisée, l'avantage étant un programme très légèrement plus
rapide).
Voilà pour mes petites réflexion, s'il y a des erreurs de logique
merci de me corriger.
Cordialement/Bises...
--
mrr
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/54ca32ea$0$3190$
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
appelé chez moi), aucun problème tant que le programme utilise un cache bien
mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
dernières commandes).
Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
c'est d'ailleurs un des principaux désavantage des librairies statiques
(avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
très légèrement plus rapide).
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
appelé chez moi), aucun problème tant que le programme utilise un cache bien
mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
dernières commandes).
Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
c'est d'ailleurs un des principaux désavantage des librairies statiques
(avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
très légèrement plus rapide).
Un programme peut être lié à une ABI de la libc de façon statique ou
dynamique.
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
appelé chez moi), aucun problème tant que le programme utilise un cache bien
mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
dernières commandes).
Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
c'est d'ailleurs un des principaux désavantage des librairies statiques
(avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
très légèrement plus rapide).
>> Ah, au fait, petite question. Après les commandes ci-dessus,
>> faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le reboo t ne
me semble pas si important que cela (aie, je prend un risque en disant
cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un sy stème
Linux sont protégés en écriture, petit rappel: .... [cut]
>> Ah, au fait, petite question. Après les commandes ci-dessus,
>> faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le reboo t ne
me semble pas si important que cela (aie, je prend un risque en disant
cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un sy stème
Linux sont protégés en écriture, petit rappel: .... [cut]
>> Ah, au fait, petite question. Après les commandes ci-dessus,
>> faut-il que je fasse un reboot ?
J'ajouterais, dans un souci d'échange et de discussion, que le reboo t ne
me semble pas si important que cela (aie, je prend un risque en disant
cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un sy stème
Linux sont protégés en écriture, petit rappel: .... [cut]
Le 28/01/2015 20:59, Philippe Deleval a écrit :Bonjour à tous
C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
ct, n), le petit n fait la différence.
Cordialement
Philippe Deleval
Et ceux qui créé la fonction strcpy sont des criminels qui devraient
être guillotinés sur le champ. Heureusement, Zorro est arrivé et a
sauvé l'informatique...
Le 28/01/2015 20:59, Philippe Deleval a écrit :
Bonjour à tous
C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
ct, n), le petit n fait la différence.
Cordialement
Philippe Deleval
Et ceux qui créé la fonction strcpy sont des criminels qui devraient
être guillotinés sur le champ. Heureusement, Zorro est arrivé et a
sauvé l'informatique...
Le 28/01/2015 20:59, Philippe Deleval a écrit :Bonjour à tous
C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
ct, n), le petit n fait la différence.
Cordialement
Philippe Deleval
Et ceux qui créé la fonction strcpy sont des criminels qui devraient
être guillotinés sur le champ. Heureusement, Zorro est arrivé et a
sauvé l'informatique...
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
appelé chez moi), aucun problème tant que le programme utilise un cache bien
mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
dernières commandes).
Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.
Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
c'est d'ailleurs un des principaux désavantage des librairies statiques
(avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
très légèrement plus rapide).
Oui, pour les liens statiques, aucun impact sans passer par une recompilation.
C'est donc hors-champ.
Un autre avantage des liens statiques, c'est le coté transportable du binaire,
tu peux le lancer sur une machine qui ne dispose pas de toutes les bibliothèques
nécessaires (puisque le programme « embarque » tous les bouts de bibliothèques
dont il a besoin).
Seb
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
appelé chez moi), aucun problème tant que le programme utilise un cache bien
mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
dernières commandes).
Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.
Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
c'est d'ailleurs un des principaux désavantage des librairies statiques
(avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
très légèrement plus rapide).
Oui, pour les liens statiques, aucun impact sans passer par une recompilation.
C'est donc hors-champ.
Un autre avantage des liens statiques, c'est le coté transportable du binaire,
tu peux le lancer sur une machine qui ne dispose pas de toutes les bibliothèques
nécessaires (puisque le programme « embarque » tous les bouts de bibliothèques
dont il a besoin).
Seb
Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
appelé chez moi), aucun problème tant que le programme utilise un cache bien
mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
dernières commandes).
Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.
Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
c'est d'ailleurs un des principaux désavantage des librairies statiques
(avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
très légèrement plus rapide).
Oui, pour les liens statiques, aucun impact sans passer par une recompilation.
C'est donc hors-champ.
Un autre avantage des liens statiques, c'est le coté transportable du binaire,
tu peux le lancer sur une machine qui ne dispose pas de toutes les bibliothèques
nécessaires (puisque le programme « embarque » tous les bouts de bibliothèques
dont il a besoin).
Seb
Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.
Je vois, au 1er appel la librairie serait mappée en mémoire puis en
quelque sorte détachée de sa source, à savoir le fichier sur le disque.
Par contre, ce qui me gène un peu c'est que cela signifierait que chaque
processus en cours d'exécution aurait sa propre copie en mémoire.
Ou il y a une autre possibilité de comprendre ta phrase qui me convient
mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée
pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout
le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et
alors elle serait "déchargée".
Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.
Je vois, au 1er appel la librairie serait mappée en mémoire puis en
quelque sorte détachée de sa source, à savoir le fichier sur le disque.
Par contre, ce qui me gène un peu c'est que cela signifierait que chaque
processus en cours d'exécution aurait sa propre copie en mémoire.
Ou il y a une autre possibilité de comprendre ta phrase qui me convient
mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée
pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout
le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et
alors elle serait "déchargée".
Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.
Je vois, au 1er appel la librairie serait mappée en mémoire puis en
quelque sorte détachée de sa source, à savoir le fichier sur le disque.
Par contre, ce qui me gène un peu c'est que cela signifierait que chaque
processus en cours d'exécution aurait sa propre copie en mémoire.
Ou il y a une autre possibilité de comprendre ta phrase qui me convient
mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée
pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout
le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et
alors elle serait "déchargée".
