Prévenir le programme de la modification d'un .so

Bonjour à tous,
j'ai un programme qui charge des fichiers .so dynamiquement, en cours d'exécution (avec dlopen() ).
Si, alors qu'un .so est chargé, je le modifie (pour mise à jour), des que mon programme veut accéder à une fonction qui etait exportée par ce .so, il plante.
Une solution (peu propre) pourrait etre qu'avant un dlopen() , je fasse une copie du fichier par programme dans un répertoire de travail, et que je supprime cette copie apres un dlclose().

Si le nombre de .so est conséquent, ca pourrait devenir lourd.

J'aimerais donc savoir s'il serait possible que soit le programme détecte une modification du .so, ou qu'il soit prévenu de l'extérieur (avec un signal) afin que je puisse le protéger du plantage ?

On m'a parlé de mmap, mais je n'ai pas vraiment compris le principe.


Merci d'avance,

eponyme

Citation:

---

Envoyé par eponyme

j'ai un programme qui charge des fichiers .so dynamiquement, en cours d'exécution (avec dlopen() ).
Si, alors qu'un .so est chargé, je le modifie (pour mise à jour), des que mon programme veut accéder à une fonction qui etait exportée par ce .so, il plante.

---

Ben oui!

Il ne faut jamais modifier un fichier en cours d'exécution!

Si tu as une MàJ à faire, tu "déconnectes" (unlink) les fichiers qui peuvent être en cours d'utilisation, et tu créé le nouveau à la place.

(Ce que ld devrait faire, AMA.)

Merci pour ta réponse.
J'ai choisi un systeme avec "signal()" qui lorsqu'il est recu, le programme décharge ses .so, et lorsqu'il est recu une seconde fois, les recharge.

eponyme

Citation:

---

Envoyé par eponyme

Merci pour ta réponse.

---

Je t'en prie.

Citation:

---

Envoyé par eponyme

J'ai choisi un systeme avec "signal()" qui lorsqu'il est recu, le programme décharge ses .so, et lorsqu'il est recu une seconde fois, les recharge.

---

Je suppose que tu sais ce qui est permis ou pas dans un gestionnaire de signal.

Je ne sais pas vraiment.
J'utilise le signal "SIGUSER1", qui "si j'ai bien compris", est avec SIGUSER2 un signal dont l'interprétation est laissée libre par l'utilisateur. Dans certains programme il est utilisé pour affihcer des infos. Je me suis donc dis que moi je pouvais l'utiliser pour prevenir le programme depuis l'extérieur qu'il fallait decharger les .so pour une mise à jour.

eponyme

Citation:

---

Envoyé par eponyme

Je ne sais pas vraiment.
J'utilise le signal "SIGUSER1", qui "si j'ai bien compris", est avec SIGUSER2 un signal dont l'interprétation est laissée libre par l'utilisateur. Dans certains programme il est utilisé pour affihcer des infos. Je me suis donc dis que moi je pouvais l'utiliser pour prevenir le programme depuis l'extérieur qu'il fallait decharger les .so pour une mise à jour.

---

Oui, les SIGUSR* sont des signaux utilisables de façon "discrétionnaire" par le programme.

Mais je parle de ce que tu fais à l'intérieur du gestionnaire de signal.

D'après ta réponse : si tu n'es pas sûr, à mon avis tu ne devrais pas utiliser un gestionnaire de signal. Je pense même qu'une personne qui a besoin de venir chercher de l'aide ici ne devrais pas s'y aventurer.

D'autre part, il y a un autre problème : comment le programme qui envoie le signal sait que le programme a reçu, et traité le signal?

(Pour moi, le fait même de se retrouver à utiliser un signal sans sémantique intrinsèque comme SIGUSR* est une absurdité, à de très rares exceptions.)

A l'interieur du gestionnaire, j'apelle une fonction qui décharger mes .so. Rien de plus.
Quelles précautions faut il prendre ?

Effectivement pour la seconde remarque, le programme externe n'a pas de visue. Cela dis c'est juste un script qui fait :
kill -s SIGUSER1 le_pid_du_programme
cp les_.so_au_bon_endroit
kill -s SIGUSER1 le_pid_du_programme

Mais effectivement, si le programme ne traite pas le signal, le script ne le saura pas.
Sinon j'ai pensé a une communication par SOCKET_UNIX. Mon programme ecouterait cette socket et un autre programme s'y connecterait pour dire de décharger les modules.
Ainsi une gestion d'erreur serait possible. En revanche, je trouve ca lourd de faire ecouter une socket pour une action qui arrivera une fois l'an ( je ne fais cela que pour la mise à jour. Je voudrais un rpm de mes .so qui pourrais facilement dire au bot de décharger ses modules lors d'une mise à jour via rpm).

eponyme

ps: je verrais le reste de tes réponses demain ;)

Citation:

---

Envoyé par eponyme

A l'interieur du gestionnaire, j'apelle une fonction qui décharger mes .so. Rien de plus.
Quelles précautions faut il prendre ?

---

Cette fonction est "async-signal safe"?

Sinon, tu ne peux pas l'appeler depuis un gestionnaire de signal.

Je doute qu'il soit possible de faire une opération aussi complexe que décharger des fichiers objets, ce qui implique normalement d'exécuter le code de nettoyage (_fini je crois), de façon async-signal safe. Ça m'étonnerai énormément.

Citation:

---

Envoyé par eponyme

Effectivement pour la seconde remarque, le programme externe n'a pas de visue. Cela dis c'est juste un script qui fait :
kill -s SIGUSER1 le_pid_du_programme
cp les_.so_au_bon_endroit
kill -s SIGUSER1 le_pid_du_programme

---

kill dit juste au système d'envoyer un signal. Au moment où il retourne, on ne sait même pas si le programme a eu la main pour recevoir le signal, encore moins s'il a eu le temps de décharger les objets dynamiques.

On a donc une magnifique race-condition.

Au fait, pourquoi utiliser cp et pas install?

Citation:

---

Envoyé par eponyme

Mais effectivement, si le programme ne traite pas le signal, le script ne le saura pas.
Sinon j'ai pensé a une communication par SOCKET_UNIX. Mon programme ecouterait cette socket et un autre programme s'y connecterait pour dire de décharger les modules.
Ainsi une gestion d'erreur serait possible.

---

La socket :

• peut être lue normalement, sans passer par un gestionnaire de signal, ou toute fonction appelée de façon asynchrone
• permet de transmettre des données
• permet d'envoyer un acquittement (ou une erreur), ce qui permet de savoir quand une requête a été prise en compte
• peut être utilisée par des processus de PID différent (selon les droit d'accès choisis)

Pour moi, c'est un véritable outil de communication inter-processus.

Citation:

---

Envoyé par eponyme

En revanche, je trouve ca lourd de faire ecouter une socket pour une action qui arrivera une fois l'an ( je ne fais cela que pour la mise à jour. Je voudrais un rpm de mes .so qui pourrais facilement dire au bot de décharger ses modules lors d'une mise à jour via rpm).

---

Après, pour la MàJ, encore une fois je pense que le problème ne se pose même pas, parce qu'il suffit de supprimer les anciens fichiers pour ne pas avoir de problème, et que je pense que c'est précisément ce que rpm (ou install) va faire (sinon c'est un sérieux bug de rpm/install).

Salut,
j'utilise :
signal(SIGUSER1,signalHandler);

et dans signalHandler() , je décharge mes .so.

La socket semble effectivement la meilleure soultion. Si effectivement rpm remplacera/supprimera les anciens fichiers, le truc c'est qu'il faut simplement qu'il attende que le programme est déchargé ses .so.

eponyme

Apres quelques tests, il semble que quand j'intercepte le signal, ensuite le programme est "perdu".

Je pense finalement utiliser un pthread qui ecoutera une socket AF_UNIX et qui gerera le chargement ou déchargement.

Merci pour l'aide.

eponyme