Equivalent C au set_terminate de C++

**PoZZyX** · 19/03/2010, 11h14

Bonjour à toutes et à tous,

Je code un programme sur linux qui est sensé tourner constamment, mais j'aimerais quand même faire un peu le ménage si il est quitté par un CTRL-C ou kill.

Du coup j'ai pensé à set_terminate, mais je vois qu'il n'existe pas en C.Y-a-t'il un moyen équivalent ?

De plus, cette partie de code va-t-elle bien s'exécuter si on kill le logiciel ou si on CTRL-C ?

Merci d'avance pour votre aide !!!

**Médinoc** · 19/03/2010, 12h30

Je ne crois pas qu'il y ait grand-chose en C standard, mais sous POSIX*, tu as la gestion de signaux. Elle peut faire du nettoyage en cas de Ctrl+C (SIGINT, SIGTERM et cie), mais pas en cas de kill: RIEN ne peut faire QUOI QUE CE SOIT en cas de kill.

*Je sais qu'il y a un peu de gestion de signaux aussi en standard, mais je ne sais jamais quels signaux elle "connait". Je sais en tout cas que c'est beaucoup moins que POSIX.

**mikhailo** · 19/03/2010, 12h38

Je viens de voir qu'il y avait la librairie <signal.h> en C standard, et on peut gérer les différents signaux.

Il y a une explication ici, par ex: http://www.xgc.com/manuals/xgclib/c1632.html

**Médinoc** · 19/03/2010, 12h59

Tiens, tous les signaux qui ici nous intéressent sont ANSI. Je n'aurais pas cru...

**Obsidian** · 19/03/2010, 14h36

Envoyé par PoZZyX

Bonjour à toutes et à tous,

Je code un programme sur linux qui est sensé tourner constamment, mais j'aimerais quand même faire un peu le ménage si il est quitté par un CTRL-C ou kill.

Du coup j'ai pensé à set_terminate, mais je vois qu'il n'existe pas en C.Y-a-t'il un moyen équivalent ?

C'est normal car c'est une opération qui dépend du système sur lequel tu tournes et pas du langage à proprement parler (ce n'est pas la libC qui gère Ctrl-C). Il faut que tu fasse un gestionnaire de signal pour intercepter les signaux qui t'intéressent. Attention à choisir les bons. Voir pour cela man signal, man sigaction et man 7 signal.

Tu peux regarder cette discussion également.

Envoyé par Médinoc

Tiens, tous les signaux qui ici nous intéressent sont ANSI. Je n'aurais pas cru...

Ça m'a surpris aussi, la première fois…

**PoZZyX** · 22/03/2010, 10h29

Merci pour toutes ces réponses. Je me pose une autre question maintenant. Un programme qui tourne constamment (toujours sur linux), comment le terminer sans le killer (lui dire de se terminer et que je puisse récupérer le message afin de faire un peu de nettoyage).

Merci d'avance

**Jean-Marc.Bourguet** · 22/03/2010, 11h30

Envoyé par PoZZyX

Merci pour toutes ces réponses. Je me pose une autre question maintenant. Un programme qui tourne constamment (toujours sur linux), comment le terminer sans le killer (lui dire de se terminer et que je puisse récupérer le message afin de faire un peu de nettoyage).

Merci d'avance

kill sert a envoyer un signal, si tu le traites tu fais ce que tu veux (pour autant que ce soit un signal interceptable).

La tradition Unix pour les demons veut que
- SIGTERM soit une demande de fin (c'est interceptable), c'est ce que tu veux (SIGTERM est d'ailleurs ce que le programme kill envoie par defaut, kill -9 c'est SIGKILL qui est envoye et SIGKILL n'est pas interceptable)
- SIGHUP soit une demande de relire la configuration

**PoZZyX** · 25/03/2010, 14h06

Merci pour toutes ces réponses, cela fonctionne effectivement à merveille avec signal.h et sigterm !!!

Merci encore

**Obsidian** · 25/03/2010, 15h56

Bonjour,

Envoyé par Jean-Marc.Bourguet

- SIGHUP soit une demande de relire la configuration

SIGHUP une demande de relecture de la config ? Je ne pense pas. Il n'y a pas de signal dédié à cela, mais c'est généralement à SIGUSR1 que l'on attribue cette tâche, de manière à ce que l'utilisateur puisse le faire.

SIGHUP signifie « Hang Up » (« raccrocher ») et était envoyé quand une liaison téléphonique était coupée, volontairement ou non, et que l'on perdait le signal du modem. Comme on n'utilise pratiquement plus de liaison série distante pour exploiter des terminaux physiques, ce sont généralement les terminaux virtuels de X qui envoient ce signal quand ils sont refermés et qu'un processus y est toujours relié. C'est d'ailleurs pour cela que l'on a créé « nohup ». Dans tous les cas, par défaut, c'est la mort du processus.

SIGHUP sur Wikipédia (en).

**Jean-Marc.Bourguet** · 25/03/2010, 16h23

Envoyé par Obsidian

SIGHUP une demande de relecture de la config ?

Envoyé par Richard Stevens in Advanced Programming in the Unix Environment

SIGHUP: [...] This signal is commonly used to notify daemon processes to reread their configuration.

Et ca correspond a mes souvenirs de quand je faisais de l'admin.

Je suis d'accord, c'est de la surchage par rapport a sa definition quand il y a un terminal controlant (et le [...] chez Stevens c'est pour expliquer le cas). Mais il n'y a pas de terminal controlant pour les terminaux, donc la surcharge n'a pas d'effet nuisible.

Edit:

Envoyé par Wikipedia en

Signals have always been a convenient method of inter-process communication (IPC), but in early implementations there were no user-definable signals (such as the later additions of SIGUSR1 and SIGUSR2) that programs could intercept and interpret for their own purposes. For this reason, applications that did not require a controlling terminal, such as daemons, would re-purpose SIGHUP as a signal to re-read configuration files, or reinitialize. This convention survives to this day in packages such as Apache and Sendmail.