Sui sistemi POSIX, segnali di terminazione di solito hanno il seguente ordine (secondo molte pagine di manuale e POSIX Spec):In che modo SIGINT si riferisce agli altri segnali di terminazione?
SIGTERM - cortesemente chiedere un processo per terminare. Termina con grazia, pulendo tutte le risorse (file, prese, processi figlio, ecc.), Cancellando file temporanei e così via.
SIGQUIT - richiesta più valida. Dovrà terminare in modo ingiustificato, ripulendo comunque le risorse che devono assolutamente essere pulite, ma forse non eliminare i file temporanei, magari scrivere da qualche parte informazioni di debug; su alcuni sistemi verrà scritto anche un core dump (indipendentemente dal fatto che il segnale venga catturato dall'app o meno).
SIGKILL - richiesta più valida. Il processo non viene nemmeno chiesto di fare nulla, ma il sistema pulirà il processo, che sia così o meno. Molto probabilmente viene scritto un dump principale.
Come si inserisce SIGINT in quell'immagine? Un processo CLI viene solitamente terminato da SIGINT quando l'utente preme CRTL + C, tuttavia un processo in background può anche essere terminato da SIGINT usando l'utilità KILL. Quello che non posso vedere nelle specifiche o nei file di intestazione è se SIGINT è più o meno potente di SIGTERM o se c'è qualche differenza tra SIGINT e SIGTERM.
UPDATE:
La migliore descrizione dei segnali di terminazione che ho trovato finora è nel GNU LibC Documentation. Spiega molto bene che esiste una differenza tra SIGTERM e SIGQUIT.
che dice di SIGTERM:
E 'il modo normale di chiedere gentilmente un programma per terminare.
E dice di SIGQUIT:
[...] e produce un core dump quando si termina il processo, proprio come un segnale di errore di programma. Si può pensare a questo come una condizione di errore del programma "rilevata" dall'utente. [...] Alcuni tipi di pulizie sono meglio omessi nella gestione di SIGQUIT. Ad esempio, se il programma crea file temporanei, deve gestire le altre richieste di terminazione eliminando i file temporanei . Ma è meglio per SIGQUIT non cancellarli, in modo che l'utente possa esaminarli nella congiunzione con il core dump.
E SIGHUP è anche spiegato abbastanza bene. SIGHUP non è in realtà un segnale di terminazione, significa solo che la "connessione" all'utente è andata persa, quindi l'app non può aspettarsi che l'utente legga ulteriori output (es. Output stdout/stderr) e non ci sono input da aspettarsi dal utente ancora. Per la maggior parte delle app significa che è meglio smettere. In teoria, un'app potrebbe anche decidere di passare alla modalità daemon quando viene ricevuto un SIGHUP e ora viene eseguito come processo in background, scrivendo l'output in un file di registro configurato. Per la maggior parte dei daemon già in esecuzione in background, SIGHUP di solito significa che devono riesaminare i loro file di configurazione, in modo da inviarlo ai processi in background dopo aver modificato i file di configurazione.
Tuttavia non esiste alcuna spiegazione utile di SIGINT su questa pagina, oltre a quella inviata da CRTL + C. C'è qualche ragione per cui si dovrebbe gestire SIGINT in modo diverso rispetto a SIGTERM? In caso affermativo, quale sarebbe la ragione e come sarebbe diversa la gestione?
Buona domanda. Sospetto che alcuni degli storici Unix cruft siano coinvolti nella risposta. –
So che questa domanda è vecchia, ma nel caso qualcuno venisse qui per una lunga lista di segnali per il proprio sistema operativo (Linux), è possibile trovarli digitando 'sudo fuser -l' sul prompt dei comandi. Per me viene visualizzato: 'HUP INT QUIT ILL TRAP ABRT IOT BUS FPE KILL USR1 SEGV USR2 TUBO ALRM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH IO PWR SYS UNUSED' –
Prova anche 'kill -l' per una lista di segnali. – AAAfarmclub