Laboratorio di Sistemi Operativi

Transcript

1 Laboratorio di Sistemi Operativi Segnali a.a. 2011/2012 Francesco Fontanella

2 Segnali - Introduzione I segnali sono interrupt software a livello di processo comunicano al processo il verificarsi di un evento ad ogni evento corrisponde un segnale numerato Permettono la gestione di eventi asincroni che interrompono il normale funzionamento di un processo a.a. 2011/2012 2

3 Segnali: breve storia La versione "non affidabile" è stata introdotte dalle prime versioni di UNIX: segnali potevano essere persi Unix 4.3BSD e SySVR3 introducono segnali affidabili : Si evita la possibilità che un segnale vada perso POSIX.1 standardizza la gestione dei segnali a.a. 2011/2012 3

4 Segnali - Introduzione Caratteristiche dei segnali Ogni segnale è identificato da una costante (definita nel file signal.h) che inizia con i tre caratteri SIG ES: SIGABRT è il segnale di abort Numero segnali: 15-40, a seconda della versione di UNIX POSIX: 18 Linux: 38 Il numero 0 identifica il segnale nullo (null signal) a.a. 2011/2012 4

5 Segnali - Introduzione I segnali sono eventi asincroni, gestiti tramite delle funzioni definite ad hoc, chiamate signal handler. Il principio di funzionamento dei segnali è il seguente Se e quando arriva un certo segnale, esegui questa funzione a.a. 2011/2012 5

6 Condizioni che possono generare segnali Combinazione di tasti speciali sul terminale Es: Premere il tasto Ctrl-C genera il segnale SIGINT Eccezioni hardware Divisione per 0 (SIGFPE) Riferimento non valido a memoria (SIGSEGV) L'interrupt viene generato dall'hardware, e catturato dal kernel; questi invia il segnale al processo in esecuzione La syscall kill permette di spedire un segnale ad un altro processo Limitazione: UID del processo che esegue kill deve essere lo stesso del processo a cui si spedisce il segnale, oppure deve essere 0 (root) a.a. 2011/2012 6

7 Condizioni che possono generare un segnale Comando kill Interfaccia shell alla syscall kill: ES: ~$ kill TERM <PID_of_proc_to_kill> ~$ kill 9 <PID_of_proc_to_kill> Condizioni software Eventi asincroni generati dal software del sistema operativo, non dall'hardware della macchina Esempi: terminazione di un child (SIGCHLD) generazione di un alarm (SIGALRM) a.a. 2011/2012 7

8 Segnali - Azioni associate Ignorare il segnale Alcuni segnali che non possono essere ignorati: SIGKILL e SIGSTOP Perchè?: è necessario consentire al superutente di terminare i processi Segnali hardware: comportamento non definito in POSIX se ignorati Azione di default Per molti segnali "critici" quest'azione è la terminazione del processo Può essere generato un file di core dump a.a. 2011/2012 8

9 Segnali - Azioni associate Catturare ("catch") il segnale: Il kernel informa il processo chiamando una funzione specificata dal processo stesso (signal handler) Il signal handler gestisce il problema nel modo più opportuno Esempio: Se si riceve il segnale SIGTERM (terminazione standard), possibile azioni potrebbero essere: rimozione dei file temporanei, salvare file a.a. 2011/2012 9

10 Signal handler Handler: SO signal movl pushl addl movl... a.a. 2011/

11 Alcuni segnali NOME AZIONE NOTA SIGABRT terminazione, core dump Generato dalla syscall abort(); terminazione anormale SIGALRM terminazione Generato da un timer settato con la syscall alarm o la funzione setitimer SIGBUS terminazione, core dump Indica un hardware fault (definito dal s.o.) SIGCHLD ignore Quando un processo termina, SIGCHLD viene spedito al processo parent SIGFPE terminazione, core dump Eccezione aritmetica, come divisioni per 0 SIGHUP terminazione Inviato ad un processo se il terminale viene disconnesso SIGILL terminazione, core dump Il processo ha eseguito un'azione illegale SIGINT terminazione Il processo ha ricevuto un carattere di interruzione (Ctrl-C) dal terminale SIGIO terminazione, ignore Evento I/O asincrono, non POSIX a.a. 2011/

12 Alcuni segnali NOME AZIONE NOTA SIGKILL terminazione Maniera sicura per uccidere un processo: non può essere intercettato SIGPIPE terminazione Scrittura su pipe/socket chiusa in lettura SIGSEGV terminazione, core dump Il processo ha eseguito un riferimento di memoria non valido SIGSYS terminazione, core dump Il processo ha eseguito una syscall non valida (Es. parametro errato) SIGTERM terminazione Segnale di default generato dal comando kill SIGURG ignore dati out-of-band ricevuti da una connessione di rete, non POSIX SIGUSR1, terminazione Segnali non definiti, utilizzabili a livello utente SIGUSR2 SIGTSTP sospensione Generato quando un processo riceve un carattere di suspend (Ctrl-Z) dal terminale a.a. 2011/

13 Funzione signal Funzione void (*signal(int signo, void (*func)(int)))(int); Descrizione: signo: l'identificatore del segnale che si vuole catturare func: l'azione da eseguire (l'handler) SIG_IGN: ignora il segnale (non applicabile a SIGKILL e SIGSTOP) SIG_DFL: azione di default l'indirizzo del signal handler: quando si vuole catturare il segnale (non applicabile a SIGKILL e SIGSTOP) valore di ritorno: il valore del precedente signal handler (per un eventuale ripristino), oppure SIG_ERR in caso di errore a.a. 2011/

14 Segnali - Generazione Syscall: int kill(pid_t pid, int signo); La funzione kill spedisce un segnale ad un processo oppure a un gruppo di processi Argomento pid: pid > 0 spedito al processo identificato da pid pid == 0 spedito a tutti i processi appartenenti allo stesso gruppo del processo che invoca kill pid < -1 spedito al gruppo di processi identificati da pid Pid == -1 non definito Argomento signo: Numero di segnale spedito La funzione restituisce 0 se in caso di successo, -1 altrimenti a.a. 2011/

15 Segnali - Generazione Syscall: int kill(pid_t pid, int signo); Il superutente può spedire segnali a chiunque Altrimenti, il real uid o l'effective uid del processo chiamante (sorgente) deve essere uguale al real uid o l'effective uid del destinatario La syscall kill è asincrona (non bloccante): il processo mittente prosegue immediatamente mentre al destinatario viene notificato il segnale a.a. 2011/

16 Segnali - Generazione POSIX.1 definisce il segnale 0 come il null signal Se il segnale spedito è null, kill esegue i normali meccanismi di controllo errore senza spedire segnali ES: verifica dell'esistenza di un processo; spedizione del null signal al processo (attenzione però: i process id vengono riciclati!) Syscall: int raise(int signo); Spedisce il segnale al processo chiamante a.a. 2011/

17 Segnali - Generazione Syscall: unsigned int alarm(unsigned int sec); Questa funzione permette di creare un allarme che verrà generato dopo il numero specificato di secondi Allo scadere del tempo, il segnale SIGALRM viene generato Attenzione: il sistema non è real-time Garantisce che la pausa sarà almeno di sec secondi Il meccanismo di scheduling può ritardare l'esecuzione di un processo Esiste un unico allarme per processo Se un allarme è già settato, il numero di secondi rimasti prima dello scadere viene ritornato da alarm Se sec è uguale a zero, l'allarme preesistente viene generato a.a. 2011/

18 Segnali - Generazione Syscall: unsigned int alarm(unsigned int sec); L'azione di default per SIGALRM è di terminare il processo Ma normalmente viene definito un signal handler per il segnale Syscall: int getitimer(int which, struct itimerval *value); int setitimer(int which, const struct itimerval *value, struct itimerval *ovalue); Permettono un controllo più completo Syscall: int pause(); Questa funzione sospende il processo fino a quando un segnale non viene catturato Ritorna 1 e setta errno a EINTR a.a. 2011/

19 Segnali - Esempio #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <signal.h> File sigusr.c void catch_signal(int sn) { printf("catch_signal: catched signal: %d\n", sn); } return; int main() { // Si intercettano i segnali SIGUSR1 e SIGUSR2 if (signal(sigusr1, handler)== SIG_ERR) perror( prima signal non riuscita\n ); if (signal(sigusr2, handler)== SIG_ERR) perror( seconda signal non riuscita\n ); Cattura i segnali definiti dall'utente e stampa un messaggio printf("waiting for signal SIGUSR1 or SIGUSR2 \n"); for (;;) ; } return 0; a.a. 2011/

20 Segnali - Esempio Output del programma: $ a.out & [1] 2951 Waiting for signal SIGUSR1 or SIGUSR2 $ kill USR catch_signal: catched signal: 10 $ kill USR catch_signal: catched signal: 12 $ kill [1] + Terminated a.out & ESERCIZIO 1 Modificare il programma precedente in maniera tale da evitare il busy waiting (ciclo for vuoto) ESERCIZIO 2 Modificare il programma precedente in maniera tale da intercettare il segnale SIGSTP, generato dall'utente premendo Ctrl^Z a.a. 2011/

21 Syscall kill(): esempio #include <stdio.h> #include <signal.h> #define MAX_WAIT 10 int cont=0; void handler(int signo) { printf ("Proc. %d: ricevuti n. %d segnali %d\n", getpid(),cont++, signo); } int main () { int pid; if (signal(sigusr1, handler)== SIG_ERR) perror( prima signal non riuscita\n ); } pid = fork(); if (pid == 0) /* figlio */ for (;;) pause(); else /* padre */ for(;;) { sleep(rand()% MAX_WAIT) kill(pid, SIGUSR1); a.a. 2011/

22 Segnali Syscall sleep() Sysem call: unsigned int sleep(unsigned int seconds); Causa la sospensione del processo fino a quando: L'ammontare di tempo specificato trascorre return value: 0 un segnale viene catturato e il signal handler effettua un return return value: tempo rimasto prima del completamento della sleep NOTA: la sleep può concludersi DOPO il tempo richiesto (no real time) a.a. 2011/

23 Syscall sleep(): Esempio #include <signal.h> void stampa(int signo) { printf("sono stato risvegliato!!\n"); } int main() { int k; } signal(sigusr1, stampa); k=sleep(1000); printf("valore di k: %d\n", k); exit(0); a.a. 2011/

24 Segnali Syscall Syscall: void abort(); questa syscall spedisce il segnale SIGABRT al processo comportamento in caso di: SIG_DFL: terminazione del processo SIG_IGN: non ammesso signal handler: il segnale viene catturato nel caso che il segnale venga catturato, il signal handler: può eseguire return può invocare exit o _exit in entrambi i casi, il processo viene terminato motivazioni per il catching: cleanup a.a. 2011/

25 Segnali - Startup Quando un programma esegue una syscall fork: I signal catcher settati nel parent vengono copiati nel figlio Quando un programma viene eseguito tramite exec Se il signal catcher per un certo segnale è default o ignore, viene lasciato inalterato nel child Se il signal catcher è settato ad una particolare funzione, viene cambiato a default nel child Motivazione: la funzione settato può non esistere più nel figlio Casi particolari Quando un processo viene eseguito in background Segnali SIGINT e SIGQUIT vengono settati a ignore In che momento / da chi questa operazione viene effettuata? a.a. 2011/

26 Esercizio: Ping - Pong Scrivere un programma che genera due processi che si scambiano segnali (SIGUSR1 o SIGUSR2) per un numero N di volte 1 Il valore di N deve essere passato alla riga di comando 2 Il primo a lanciare un segnale deve essere il padre 3 Il signal handler deve visualizzare il pid del processo e il numero di volte che è stato intercettato Suggerimenti: Utilizzare le syscall sleep() e pause() a.a. 2011/

27 Esercizio: Sincronizzazione tramite segnali realizzare un meccanismo basato su segnali per risolvere il problema produttore / consumatore processo padre:il produttore produce numeri interi consecutivi stampa il proprio pid e il numero prodotto processo figlio: consumatore, consuma i numeri prodotti dal padre stampa il proprio pid e il numero consumato I due processi utilizzano un buffer di dimensione 1, realizzato con un file condiviso a.a. 2011/

28 Esercizio: Sincronizzazione tramite segnali processo padre: apre il file condiviso in scrittura utilizza lseek per scrivere sempre all'inizio scrive i 4 byte che rappresentano un int processo figlio: apre il file condiviso in lettura utilizza lseek per leggere sempre all'inizio legge i 4 byte che rappresentano un int a.a. 2011/