Une question me taraude l'esprit. J'ai une application qui génère à
la demande un core (sans s'interrompre, en fait). Le core est bon
puisqu'avec un débugger (ddd), j'arrive à voir que le pointeur
programme est au bon endroit, avec les bonnes variables... Donc tout
est parfait. Mais comment redémarrer ce truc au point où il en était
lors de la création du core ?
J'ai tout essayé, sans succès... Une idée ?
JKB
--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 19-03-2005, à propos de Re: Comment redémarrer un processus depuis son core ?, [...]
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans les systèmes POSIX un tel appel. Le processus reçoit un signal, fait une image de lui-même (avec l'exécutable, pas un simple core) que l'on peut relancer plus tard (sur le même système bien entendu). Je comprends bien le problème des sockets ouvertes et des fichiers, mais avec ses restrictions, ce serait vraiment utile.
J'ai entendu parlé d'un lib qui permet de faire des images de binaires et de les transbahuter sur un système clône et les faire repartir. Je ne parle pas de langages dédiés mais de prendre une tâche quelconque... Un pote y a bossé dessus dans son projet de fin d'étude DESS Génie Log. Je lui poserais la question quand il sera réveillé ;-)
FAb (d'ailleurs si vous cherchez un ingé génie log, contactez-moi :-) http://mendes.fabrice.free.fr/CV/ )
JKB <knatschke@koenigsberg.fr> writes:
Le 19-03-2005, à propos de
Re: Comment redémarrer un processus depuis son core ?,
[...]
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans
les systèmes POSIX un tel appel. Le processus reçoit un signal, fait
une image de lui-même (avec l'exécutable, pas un simple core) que
l'on peut relancer plus tard (sur le même système bien entendu). Je
comprends bien le problème des sockets ouvertes et des fichiers,
mais avec ses restrictions, ce serait vraiment utile.
J'ai entendu parlé d'un lib qui permet de faire des images de binaires et de les
transbahuter sur un système clône et les faire repartir. Je ne parle pas de
langages dédiés mais de prendre une tâche quelconque... Un pote y a bossé dessus
dans son projet de fin d'étude DESS Génie Log. Je lui poserais la question quand
il sera réveillé ;-)
FAb
(d'ailleurs si vous cherchez un ingé génie log, contactez-moi :-)
http://mendes.fabrice.free.fr/CV/ )
Le 19-03-2005, à propos de Re: Comment redémarrer un processus depuis son core ?, [...]
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans les systèmes POSIX un tel appel. Le processus reçoit un signal, fait une image de lui-même (avec l'exécutable, pas un simple core) que l'on peut relancer plus tard (sur le même système bien entendu). Je comprends bien le problème des sockets ouvertes et des fichiers, mais avec ses restrictions, ce serait vraiment utile.
J'ai entendu parlé d'un lib qui permet de faire des images de binaires et de les transbahuter sur un système clône et les faire repartir. Je ne parle pas de langages dédiés mais de prendre une tâche quelconque... Un pote y a bossé dessus dans son projet de fin d'étude DESS Génie Log. Je lui poserais la question quand il sera réveillé ;-)
FAb (d'ailleurs si vous cherchez un ingé génie log, contactez-moi :-) http://mendes.fabrice.free.fr/CV/ )
JKB
Le 19-03-2005, à propos de Re: Comment redémarrer un processus depuis son core ?, FAb écrivait dans fr.comp.os.unix :
JKB writes:
Le 19-03-2005, à propos de Re: Comment redémarrer un processus depuis son core ?, [...]
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans les systèmes POSIX un tel appel. Le processus reçoit un signal, fait une image de lui-même (avec l'exécutable, pas un simple core) que l'on peut relancer plus tard (sur le même système bien entendu). Je comprends bien le problème des sockets ouvertes et des fichiers, mais avec ses restrictions, ce serait vraiment utile.
J'ai entendu parlé d'un lib qui permet de faire des images de binaires et de les transbahuter sur un système clône et les faire repartir. Je ne parle pas de langages dédiés mais de prendre une tâche quelconque... Un pote y a bossé dessus dans son projet de fin d'étude DESS Génie Log. Je lui poserais la question quand il sera réveillé ;-)
Ça m'intéresse ;-)
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 19-03-2005, à propos de
Re: Comment redémarrer un processus depuis son core ?,
FAb écrivait dans fr.comp.os.unix :
JKB <knatschke@koenigsberg.fr> writes:
Le 19-03-2005, à propos de
Re: Comment redémarrer un processus depuis son core ?,
[...]
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans
les systèmes POSIX un tel appel. Le processus reçoit un signal, fait
une image de lui-même (avec l'exécutable, pas un simple core) que
l'on peut relancer plus tard (sur le même système bien entendu). Je
comprends bien le problème des sockets ouvertes et des fichiers,
mais avec ses restrictions, ce serait vraiment utile.
J'ai entendu parlé d'un lib qui permet de faire des images de binaires et de les
transbahuter sur un système clône et les faire repartir. Je ne parle pas de
langages dédiés mais de prendre une tâche quelconque... Un pote y a bossé dessus
dans son projet de fin d'étude DESS Génie Log. Je lui poserais la question quand
il sera réveillé ;-)
Ça m'intéresse ;-)
JKB
--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 19-03-2005, à propos de Re: Comment redémarrer un processus depuis son core ?, FAb écrivait dans fr.comp.os.unix :
JKB writes:
Le 19-03-2005, à propos de Re: Comment redémarrer un processus depuis son core ?, [...]
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans les systèmes POSIX un tel appel. Le processus reçoit un signal, fait une image de lui-même (avec l'exécutable, pas un simple core) que l'on peut relancer plus tard (sur le même système bien entendu). Je comprends bien le problème des sockets ouvertes et des fichiers, mais avec ses restrictions, ce serait vraiment utile.
J'ai entendu parlé d'un lib qui permet de faire des images de binaires et de les transbahuter sur un système clône et les faire repartir. Je ne parle pas de langages dédiés mais de prendre une tâche quelconque... Un pote y a bossé dessus dans son projet de fin d'étude DESS Génie Log. Je lui poserais la question quand il sera réveillé ;-)
Ça m'intéresse ;-)
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
talon
JKB wrote:
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans les systèmes POSIX un tel appel. Le processus reçoit un signal, fait une image de lui-même (avec l'exécutable, pas un simple core) que l'on peut relancer plus tard (sur le même système bien entendu). Je comprends bien le problème des sockets ouvertes et des fichiers, mais avec ses restrictions, ce serait vraiment utile.
Je t'ai déjà mentionné plusieurs fois un système qui fait tout ça y
compris sauvegarder et restaurer une partie de l'état "externe" du programme: HEAD now has the checkpointing code fully integrated, including syscall and signal support, and manual pages which describe its operation.
See sys_checkpoint(2) and checkpt(1) for details. Donc tu as bien un exemple concret qui implémente ce que désires, avec le code source, que tu peux même repomper intégralement dans ton business parcequ'il est *libre*.
--
Michel TALON
JKB <knatschke@koenigsberg.fr> wrote:
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans
les systèmes POSIX un tel appel. Le processus reçoit un signal, fait
une image de lui-même (avec l'exécutable, pas un simple core) que
l'on peut relancer plus tard (sur le même système bien entendu). Je
comprends bien le problème des sockets ouvertes et des fichiers,
mais avec ses restrictions, ce serait vraiment utile.
Je t'ai déjà mentionné plusieurs fois un système qui fait tout ça y
compris sauvegarder et restaurer une partie de l'état "externe" du
programme:
HEAD now has the checkpointing code fully integrated, including syscall
and signal support, and manual pages which describe its operation.
See sys_checkpoint(2) and checkpt(1) for details.
Donc tu as bien un exemple concret qui implémente ce que désires, avec
le code source, que tu peux même repomper intégralement dans ton business
parcequ'il est *libre*.
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans les systèmes POSIX un tel appel. Le processus reçoit un signal, fait une image de lui-même (avec l'exécutable, pas un simple core) que l'on peut relancer plus tard (sur le même système bien entendu). Je comprends bien le problème des sockets ouvertes et des fichiers, mais avec ses restrictions, ce serait vraiment utile.
Je t'ai déjà mentionné plusieurs fois un système qui fait tout ça y
compris sauvegarder et restaurer une partie de l'état "externe" du programme: HEAD now has the checkpointing code fully integrated, including syscall and signal support, and manual pages which describe its operation.
See sys_checkpoint(2) and checkpt(1) for details. Donc tu as bien un exemple concret qui implémente ce que désires, avec le code source, que tu peux même repomper intégralement dans ton business parcequ'il est *libre*.
--
Michel TALON
JKB
Le 19-03-2005, à propos de Re: Comment redémarrer un processus depuis son core ?, Michel Talon écrivait dans fr.comp.os.unix :
JKB wrote:
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans les systèmes POSIX un tel appel. Le processus reçoit un signal, fait une image de lui-même (avec l'exécutable, pas un simple core) que l'on peut relancer plus tard (sur le même système bien entendu). Je comprends bien le problème des sockets ouvertes et des fichiers, mais avec ses restrictions, ce serait vraiment utile.
Je t'ai déjà mentionné plusieurs fois un système qui fait tout ça y
compris sauvegarder et restaurer une partie de l'état "externe" du programme: HEAD now has the checkpointing code fully integrated, including syscall and signal support, and manual pages which describe its operation.
See sys_checkpoint(2) and checkpt(1) for details.
Quel OS ? Je regarde toujours attentivement les miens qu'on me donne, et pour l'instant, je n'ai rien trouvé de vraiment fonctionnel (y compris le lien sur DFBSD qui est inutilisable en dehors du système lui-même).
Donc tu as bien un exemple concret qui implémente ce que désires, avec le code source, que tu peux même repomper intégralement dans ton business parcequ'il est *libre*.
Ouaips... Libre peut-être, mais pas utilisable en tant que tel. J'ai aussi fureté sur checkpointing.org, et rien ne ressemble à ce que je cherche (il faut ou une libc spéciale, ou lier avec une bibliothèque spéciale façon core_restart qui correspond assez à ce que je cherche pais qui ne fonctionne pas, ou patcher un noyau...)
Cordialement,
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 19-03-2005, à propos de
Re: Comment redémarrer un processus depuis son core ?,
Michel Talon écrivait dans fr.comp.os.unix :
JKB <knatschke@koenigsberg.fr> wrote:
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans
les systèmes POSIX un tel appel. Le processus reçoit un signal, fait
une image de lui-même (avec l'exécutable, pas un simple core) que
l'on peut relancer plus tard (sur le même système bien entendu). Je
comprends bien le problème des sockets ouvertes et des fichiers,
mais avec ses restrictions, ce serait vraiment utile.
Je t'ai déjà mentionné plusieurs fois un système qui fait tout ça y
compris sauvegarder et restaurer une partie de l'état "externe" du
programme:
HEAD now has the checkpointing code fully integrated, including syscall
and signal support, and manual pages which describe its operation.
See sys_checkpoint(2) and checkpt(1) for details.
Quel OS ? Je regarde toujours attentivement les miens qu'on me
donne, et pour l'instant, je n'ai rien trouvé de vraiment
fonctionnel (y compris le lien sur DFBSD qui est inutilisable en
dehors du système lui-même).
Donc tu as bien un exemple concret qui implémente ce que désires, avec
le code source, que tu peux même repomper intégralement dans ton business
parcequ'il est *libre*.
Ouaips... Libre peut-être, mais pas utilisable en tant que tel. J'ai
aussi fureté sur checkpointing.org, et rien ne ressemble à ce que je
cherche (il faut ou une libc spéciale, ou lier avec une bibliothèque
spéciale façon core_restart qui correspond assez à ce que je cherche
pais qui ne fonctionne pas, ou patcher un noyau...)
Cordialement,
JKB
--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 19-03-2005, à propos de Re: Comment redémarrer un processus depuis son core ?, Michel Talon écrivait dans fr.comp.os.unix :
JKB wrote:
Philosophiquement, je ne comprends pas pourquoi il n'existe pas dans les systèmes POSIX un tel appel. Le processus reçoit un signal, fait une image de lui-même (avec l'exécutable, pas un simple core) que l'on peut relancer plus tard (sur le même système bien entendu). Je comprends bien le problème des sockets ouvertes et des fichiers, mais avec ses restrictions, ce serait vraiment utile.
Je t'ai déjà mentionné plusieurs fois un système qui fait tout ça y
compris sauvegarder et restaurer une partie de l'état "externe" du programme: HEAD now has the checkpointing code fully integrated, including syscall and signal support, and manual pages which describe its operation.
See sys_checkpoint(2) and checkpt(1) for details.
Quel OS ? Je regarde toujours attentivement les miens qu'on me donne, et pour l'instant, je n'ai rien trouvé de vraiment fonctionnel (y compris le lien sur DFBSD qui est inutilisable en dehors du système lui-même).
Donc tu as bien un exemple concret qui implémente ce que désires, avec le code source, que tu peux même repomper intégralement dans ton business parcequ'il est *libre*.
Ouaips... Libre peut-être, mais pas utilisable en tant que tel. J'ai aussi fureté sur checkpointing.org, et rien ne ressemble à ce que je cherche (il faut ou une libc spéciale, ou lier avec une bibliothèque spéciale façon core_restart qui correspond assez à ce que je cherche pais qui ne fonctionne pas, ou patcher un noyau...)
Cordialement,
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Jérémy JUST
On 18 Mar 2005 15:44:06 +0100 Pascal Bourguignon wrote:
Le core dump, c'est fait pour pouvoir déboguer post-mortem.
Pourtant, la documentation de Perl garde trace d'un système (maintenant désuet) pour convertir un script Perl en exécutable via un core-dump. La situation n'est pas exactement la même, puisque le core est généré alors que le programme n'a pas encore été exécuté (donc pas de problèmes de sockets, par exemple).
$ perldoc perlrun [...] -u This obsolete switch causes Perl to dump core after compiling your program. You can then in theory take this core dump and turn it into an executable file by using the undump program (not sup- plied). This speeds startup at the expense of some disk space (which you can minimize by stripping the executable). (Still, a "hello world" executable comes out to about 200K on my machine.) If you want to execute a portion of your program before dumping, use the dump() operator instead. Note: availability of undump is platform specific and may not be available for a specific port of Perl.
-- Jérémy JUST
On 18 Mar 2005 15:44:06 +0100
Pascal Bourguignon <spam@mouse-potato.com> wrote:
Le core dump, c'est fait pour pouvoir déboguer post-mortem.
Pourtant, la documentation de Perl garde trace d'un système
(maintenant désuet) pour convertir un script Perl en exécutable via un
core-dump.
La situation n'est pas exactement la même, puisque le core est généré
alors que le programme n'a pas encore été exécuté (donc pas de
problèmes de sockets, par exemple).
$ perldoc perlrun
[...]
-u This obsolete switch causes Perl to dump core after compiling your
program. You can then in theory take this core dump and turn it
into an executable file by using the undump program (not sup-
plied). This speeds startup at the expense of some disk space
(which you can minimize by stripping the executable). (Still, a
"hello world" executable comes out to about 200K on my machine.)
If you want to execute a portion of your program before dumping,
use the dump() operator instead. Note: availability of undump is
platform specific and may not be available for a specific port of
Perl.
On 18 Mar 2005 15:44:06 +0100 Pascal Bourguignon wrote:
Le core dump, c'est fait pour pouvoir déboguer post-mortem.
Pourtant, la documentation de Perl garde trace d'un système (maintenant désuet) pour convertir un script Perl en exécutable via un core-dump. La situation n'est pas exactement la même, puisque le core est généré alors que le programme n'a pas encore été exécuté (donc pas de problèmes de sockets, par exemple).
$ perldoc perlrun [...] -u This obsolete switch causes Perl to dump core after compiling your program. You can then in theory take this core dump and turn it into an executable file by using the undump program (not sup- plied). This speeds startup at the expense of some disk space (which you can minimize by stripping the executable). (Still, a "hello world" executable comes out to about 200K on my machine.) If you want to execute a portion of your program before dumping, use the dump() operator instead. Note: availability of undump is platform specific and may not be available for a specific port of Perl.
-- Jérémy JUST
talon
JKB wrote:
cherche (il faut ou une libc spéciale, ou lier avec une bibliothèque spéciale façon core_restart qui correspond assez à ce que je cherche pais qui ne fonctionne pas, ou patcher un noyau...)
Evidemment qu'il faut modifier le noyau. Comment veux tu sinon récupérer les signaux etc. Le système de checkpoint que je t'ai indiqué est fonctionnel sur DFBSD, et tu disposes du code source. C'est tout ce que je voulais dire. Je suppose que ça doit être portable sous Linux d'une façon relativement directe (et que dans ce sens là il n'y a pas besoin de mettre des cierges à tous les saints pour se prémunir contre les problèmes de licence). Evidemment un système de ce genre est utile pour tous les gens qui font des calculs longs que ce soit en Fortran, C, etc. Si tu développes un solution perso, limitée et qui ne correspond qu'à un langage finalement c'est un peu perdre son temps, non? Une solution générique qui marche quelle que soit la nature du programme dans des limites raisonnables me semble plus intéressante.
--
Michel TALON
JKB <knatschke@koenigsberg.fr> wrote:
cherche (il faut ou une libc spéciale, ou lier avec une bibliothèque
spéciale façon core_restart qui correspond assez à ce que je cherche
pais qui ne fonctionne pas, ou patcher un noyau...)
Evidemment qu'il faut modifier le noyau. Comment veux tu sinon récupérer les
signaux etc. Le système de checkpoint que je t'ai indiqué est fonctionnel sur
DFBSD, et tu disposes du code source. C'est tout ce que je voulais dire. Je
suppose que ça doit être portable sous Linux d'une façon relativement directe
(et que dans ce sens là il n'y a pas besoin de mettre des cierges à tous les
saints pour se prémunir contre les problèmes de licence).
Evidemment un système de ce genre est utile pour tous les gens qui font des
calculs longs que ce soit en Fortran, C, etc. Si tu développes un solution
perso, limitée et qui ne correspond qu'à un langage finalement c'est un peu
perdre son temps, non? Une solution générique qui marche quelle que soit
la nature du programme dans des limites raisonnables me semble plus
intéressante.
cherche (il faut ou une libc spéciale, ou lier avec une bibliothèque spéciale façon core_restart qui correspond assez à ce que je cherche pais qui ne fonctionne pas, ou patcher un noyau...)
Evidemment qu'il faut modifier le noyau. Comment veux tu sinon récupérer les signaux etc. Le système de checkpoint que je t'ai indiqué est fonctionnel sur DFBSD, et tu disposes du code source. C'est tout ce que je voulais dire. Je suppose que ça doit être portable sous Linux d'une façon relativement directe (et que dans ce sens là il n'y a pas besoin de mettre des cierges à tous les saints pour se prémunir contre les problèmes de licence). Evidemment un système de ce genre est utile pour tous les gens qui font des calculs longs que ce soit en Fortran, C, etc. Si tu développes un solution perso, limitée et qui ne correspond qu'à un langage finalement c'est un peu perdre son temps, non? Une solution générique qui marche quelle que soit la nature du programme dans des limites raisonnables me semble plus intéressante.
