(Courriels de diversion: <arrangions@diarrhees-enfantements.com> <caracteres@immiscerez-rechaufferas.com> <fourrerons@immeuble-controleras.com> <remplacons@deshabituee-derivez.com> <feodale@combattes-identifia.com> <lingerie@ambulantes-enumereraient.com> <embraie@balafrer-reprimerais.com> <saigneriez@implosera-attarde.com> <meuglement@apothicaire-exterminerait.com> <diluera@scarabees-autogeres.com> )
Le 10.04.03, jdd a tapoté : | Thomas Nemeth wrote: | | > Installer un gestionnaire de signal permet de contourner celui | > par défaut du système. En l'occurence celui par défaut fait se | > terminer l'application. En le remplaçant par une fonction ne | > faisant rien, cela permet au programme de continuer même s'il | > reçoit ce signal. | | dans les exemples que j'ai essayé, ca ne marche pas... en tout cas pas | dans le contexte avoqué en général (fonctionnement en arrière plan). le | SOGHUP est peut-être intercepté, mais ca ne suffit pas à maintenir le | processus en vie. Je n'ai jamais tenté d'intercepter SIGHUP, mais tu pourras trouver un exemple de récupération de signaux dans le serveur de guinness http://tnemeth.free.fr/projets/guinness-server.html dans guinnessd.c : void install_handler (); /* * Gestionnaire de signal SIGPIPE, SIGTERM, SIGQUIT et SIGINT * */ void handler_signaux (int sig) { switch (sig) { case SIGPIPE: printlog (LOG_NOTIFY, "Signal SIGPIPE reçu...\n"); install_handler (); break; case SIGTERM: case SIGQUIT: case SIGINT: online = FALSE; printlog (LOG_NOTIFY, "Signal de terminaison reçu...\n"); break; default: printlog (LOG_NOTIFY, "Signal reçu...\n"); } } [...] /* * Installation du gestionnaire de signal SIGPIPE et autres... * */ void install_handler () { signal (SIGPIPE, handler_signaux); signal (SIGTERM, handler_signaux); signal (SIGQUIT, handler_signaux); signal (SIGINT, handler_signaux); } | sighup devrait permettre de demander à un démon de recharger sa config | ou ses logs Ça, il te suffit de lancer la relecture du fichier de config lors de la réception de ce signal en le gérant comme les autres... Normalement :) | wget: avec nohup, pas de sortie à l'écran Pour moi c'est tout à fait normal : c'est nohup lui-même qui redirige la sortie. Ici, nohup est intégré au shell _et_ un script, mais c'est celui du shell qui est utilisé en premier : exether[guinness-server] which nohup nohup: commande intégrée au shell. exether[guinness-server] where nohup nohup est intégré(e) au shell /usr/bin/nohup exether[guinness-server] file /usr/bin/nohup /usr/bin/nohup: Bourne shell script text exether[guinness-server] echo $SHELL /usr/bin/tcsh Thomas -- BOFH excuse #58: High pressure system failure -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>