Je programme un arbre de processus sous Linux et je me demande s'il y a un signal qui peut être utilisé simplement pour envoyer d'un processus A au processus B sans affecter le processus B.
Par exemple, supposons que B_pid est l'ID du processus B, si le processus A appelle kill (B_pid, SIGSTOP); alors A mettra en pause B. Ce que je recherche est un signal, disons SIGNOTHING , que lorsque A appelle kill (B_pid, SIGNOTHING) , alors il envoie simplement un message à B plutôt que de faire quelque chose à la fois à B et le système.
4 Réponses :
SIGUSR1 et SIGUSR2 sont conçus à cet effet.
Fondamentalement, chaque signal sous Linux est associé à une action.
Page de manuel du signal:
A process can change the disposition of a signal using sigaction(2)
or signal(2). (The latter is less portable when establishing a
signal handler; see signal(2) for details.) Using these system
calls, a process can elect one of the following behaviors to occur on
delivery of the signal: perform the default action; ignore the
signal; or catch the signal with a signal handler, a programmer-
defined function that is automatically invoked when the signal is
delivered.
SIGSTOP
SIGSTOP P1990 Stop Stop process
Si vous appelez la commande suivante sur votre shell:
kill -l
vous obtenez une liste complète des signaux disponibles pour votre système.
La plupart des signaux peuvent être utilisés pour simplement les «recevoir» du côté cible. MAIS: La plupart des signaux sont également utilisés par le système lui-même pour indiquer à l'application que quelque chose de spécial s'est produit, comme SIGSEGV . Cela n'a donc aucun sens d'utiliser des signaux, qui ont une signification fixe car ils sont utilisés pour communiquer du noyau / OS à l'application.
Pour les signaux utilisateur, vous avez deux signaux réservés, qui peuvent être utilisés pour tout ce que vous aimez: SIGUSR1 et SIGUSR2.
Tous les systèmes Unix n'ont pas ces signaux! Alors regardez d'abord quels signaux peuvent être utilisés sur votre système actuel!
Conseil supplémentaire:
Vérifiez vos gestionnaires de signaux et le contexte dans lequel ils fonctionnent. Sur certaines implémentations, il n'est pas permis d'appeler des fonctions non réentrantes depuis le contexte du gestionnaire. Il est donc peut-être plus utile de communiquer via un tube ou toute autre méthode IPC.
Certains signaux sont destinés à être utilisés pour les programmes utilisateur. Depuis signal de l'homme :
Les signaux SIGKILL et SIGSTOP ne peuvent pas être capturés, bloqués ou ignorés.
SIGSTOP arrêtera toujours le programme et SIGKILL terminera toujours le programme.
Il y a généralement deux signaux définis par l'utilisateur utilisé pour la communication de signal entre les processus:
SIGUSR1 ... User-defined signal 1 SIGUSR2 ... User-defined signal 2
Et il existe également toute une gamme de signaux en temps réel à utiliser comme signaux définis par l'utilisateur entre SIGRTMIN et SIGRTMAX code >, qui doivent contenir au moins 8 signaux (c'est-à-dire SIGRTMAX - SIGRTMIN> = 8 ) et Linux prend en charge 33 signaux. Ils sont tous destinés à être utilisés par l'application utilisateur pour faire tout ce qu'elle veut.
Pourquoi quand j'ai appelé kill (B_pid, SIGUSR1); , B se termine au lieu d'attraper et d'exécuter le gestionnaire de signal voulu?
Comme vous avez déjà accepté cette réponse et que la question ici est différente, je suggère de créer une question différente sur ce sujet sur ce forum avec le exemple minimal reproductible .
Alors
SIGUSR1etSIGUSR2? Les deux seuls signaux qui ne peuvent pas être capturés sontSIGSTOPetSIGKILL. Vous pouvez tout faire avec tous les autres.man7.org/linux/man-pages/man7/signal.7. html