{"id":437,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:19","modified_gmt":"2020-08-22T20:26:19","slug":"this-is-the-page-title-toplevel-270","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=437","title":{"rendered":"Signals"},"content":{"rendered":"\nSignals<\/title>\n<p>\nSignals are a way of sending simple messages to processes. Most of these\nmessages are already defined and can be found in <linux\/signal.h>.\nHowever, signals can only be processed when the process is in <glossary>user mode<\/glossary>.\nIf a <glossary>signal<\/glossary> has been sent to a\nprocess that is in <glossary>kernel<\/glossary> mode, it is dealt with immediately on\nreturning to user mode.\n<\/p>\n<p>\nSignals are one of the oldest inter-process communication methods used by\nUnix <sup><font size=-4><tt>T<\/tt>M<\/font><\/sup> systems.\nThey are used to signal asynchronous events to one or more processes.\nA signal could be generated by a keyboard <glossary>interrupt<\/glossary> or an error condition such as the\nprocess attempting to access a non-existent location in its virtual memory.\nSignals are also used by the shells to signal job control commands to their child processes.\n<p>\nThere are a set of defined signals that the kernel can generate or that can be\ngenerated by other processes in the system, provided that they have the correct\nprivileges.\nYou can list a system’s set of signals using the <font face=\"helvetica\">kill<\/font> command (kill -l), on my Intel\nLinux box this gives:\n<table>\n<tr><td> 1) SIGHUP<td> 2) SIGINT<td> 3) SIGQUIT<td> 4) SIGILL\n<tr><td> 5) SIGTRA<td> 6) SIGIOT<td> 7) SIGBUS<td> 8) SIGFPE\n<tr><td> 9) SIGKILL<td>10) SIGUSR1<td>11) SIGSEGV<td>12) SIGUSR2\n<tr><td>13) SIGPIPE<td>14) SIGALRM<td>15) SIGTERM<td>17) SIGCHLD\n<tr><td>18) SIGCONT<td>19) SIGSTOP<td>20) SIGTSTP<td>21) SIGTTIN\n<tr><td>22) SIGTTOU<td>23) SIGURG<td>24) SIGXCPU<td>25) SIGXFSZ\n<tr><td>26) SIGVTALRM<td>27) SIGPROF<td>28) SIGWINCH<td>29) SIGIO\n<tr><td>30) SIGPWR\n<\/table>\n<p>\nThe numbers are different for an Alpha AXP Linux box.\nProcesses can choose to ignore most of the signals that are generated, with two notable\nexceptions: neither the <tt>SIGSTOP<\/tt> signal which causes\na process to halt its execution nor the <tt>SIGKILL<\/tt> signal which causes a process to\nexit can be ignored.\nOtherwise though, a process can choose just how it wants to handle the various signals.\nProcesses can block the signals and, if they do not block them, processes can either choose\nto handle the signals themselves or allow the kernel to handle them.\nIf the kernel handles the signals, it will do the default actions required for this\nsignal.\nFor example, the default action when a process receives the <tt>SIGFPE<\/tt> (floating point\nexception) signal is to core dump and then exit. Signals have no inherent relative\npriorities. If two signals are generated for a process at the same time then they may be\npresented to the process or handled in any order.\nAlso there is no mechanism for handling multiple signals of the same kind.\nThere is no way that a process can tell if it received 1 or 42 <tt>SIGCONT<\/tt> signals.\n<p>\nLinux implements signals using information stored in the <tt>task_struct<\/tt> for the\nprocess. The number of supported signals is limited to the word size of the processor.\nProcesses with a word size of 32 bits can have 32 signals whereas 64 bit processors like\nthe Alpha AXP may have up to 64 signals.\nThe currently pending signals are kept in the <tt>signal<\/tt> field with a mask of blocked\nsignals held in <tt>blocked<\/tt>.\nWith the exception of <tt>SIGSTOP<\/tt> and <tt>SIGKILL<\/tt>, all signals can be blocked.\nIf a blocked signal is generated, it remains pending until it is unblocked.\nLinux also holds information about how each process handles every possible signal and this\nis held in an array of <tt>sigaction<\/tt> data structures pointed at by the <tt>task_struct<\/tt>\nfor each process.\nAmongst other things it contains either the address of a routine that will handle\nthe signal or a flag which tells Linux that the process either wishes to ignore this\nsignal or let the <glossary>kernel<\/glossary> handle the signal for it.\nThe process modifies the default signal handling by making system calls and these calls\nalter the <tt>sigaction<\/tt> for the appropriate signal as well as the <tt>blocked<\/tt> mask.\n<p>\nNot every <glossary>process<\/glossary> in the system can send signals to every other process. For\nsecurity reason (among other things) only the\nkernel can and super users can send signals to all processes.\nNormal processes can only send signals to processes with the same <em>uid<\/em> and <em>gid<\/em> or\nto processes in the same process group.\nSignals are generated by setting the appropriate bit in the <tt>task_struct<\/tt>‘s <tt>signal<\/tt>\nfield.\nIf the process has not blocked the signal and is\nwaiting but interruptible (in state Interruptible) then it is woken up\nby changing its state to Running and making sure that it is in the run queue.\nThat way the scheduler will consider it a candidate for running when the system next\nschedules.\nIf the default handling is needed, then Linux can optimize the handling of the signal.\nFor example if the signal <tt>SIGWINCH<\/tt> (the X window changed focus) and the\ndefault handler is being used then there is nothing to be done.\n<p>\nSignals are not presented to the process immediately after they are generated. Instead, they\nmust wait until the process is running again.\nEvery time a process exits from a system call, its <tt>signal<\/tt> and <tt>blocked<\/tt> fields\nare checked and, if there are any unblocked signals, they can now be delivered.\nThis might seem a very unreliable method since it is dependant on the processes checking the signals,\nbut every process in the system is making\nsystem calls, for example to write a character to the terminal, all of the time.\nProcesses can elect to wait for signals if they wish, they are suspended in\nstate Interruptible until a signal is presented.\nThe Linux signal processing code looks at the <tt>sigaction<\/tt> structure for each of\nthe current unblocked signals.\n<p>\nIf a signal’s handler is set to the default action, then the kernel will handle\nit. The SIGSTOP signal’s default handler will change the current process’ state\nto Stopped, then run the scheduler to select a new process to run. The default\naction for the SIGFPE signal core dumps the process and then causes it to exit.\nAlternatively, a process may have specfied its own signal handler. This is a\nroutine that is called whenever the signal is generated and the sigaction\nstructure holds the routine’s address. It is the kernel’s job to call the\nprocess’ signal handling routine. How this happens is processor specific but all\nCPUs must cope with the fact that the current process that has been running in\nkernel mode is just about to return to the calling process in user mode. The\nproblem is solved by doing several things such as manipulating the process’\nstack and registers, resetting the process’ program counter to the address of\nits signal handling routine and either adding the parameters of the routine to\nthe call frame or passing in registers. Whatever the CPU’s exact mechanism, when\nthe process resumes operation it appears as if the signal handling routine had\nbeen called normally.\n<p>\nLinux is POSIX compatible and so the process can specify which signals are blocked\nwhen a particular signal handling routine is called.\nThis entails changing the <tt>blocked<\/tt> mask during the call to the processes signal handler.\nThe <tt>blocked<\/tt> mask must be returned to its original value when the signal handling\nroutine has finished.\nTherefore Linux adds a call to a tidy up routine that will restore the original\n<tt>blocked<\/tt> mask onto the call stack of the signalled process.\nLinux also optimizes the case where several signal handling routines need to be called\nby stacking them so that each time one handling routine exits, the next one is called\nuntil the tidy up routine is called.\n<!-- START James Mohr Copyright -->\n<p>\nMany signals (such as <glossary>signal<\/glossary> 9, SIGKILL), have the ability to\nimmediately terminate a process. However, most of these signals can be either\nignored or dealt with by the process itself. If not, the <glossary>kernel<\/glossary>\nwill take the default action specified for that <glossary>signal<\/glossary>.\nYou can send signals to processes yourself by means of the kill command,\nas well as by the Delete key and Ctrl+\/. However, you can only send\nsignals to processes that you own unless you are root. If you are root, you can send\nsignals to any process.\n<\/p>\n<p>\nIt’s possible that the process to which you want to send the <glossary>signal<\/glossary>\nis sleeping. If that process is sleeping at an <i>interruptible<\/i> priority, then the\nprocess will awaken to handle the signal.\n<\/p>\n<p>\nThe <glossary>kernel<\/glossary> keeps track of pending signals in each process’\nprocess structure. This is a 32-bit value in which each bit represents a single\n<glossary>signal<\/glossary>. Because it is only one bit per\n<glossary>signal<\/glossary>, there can only be one signal pending of each type. If\nthere are different kinds of signals pending, the <glossary>kernel<\/glossary>\nhas no way of determining which came in when. It will therefore process the signals\nstarting at the lowest numbered <glossary>signal<\/glossary> and moving up.\n<\/p>\n<!-- END James Mohr Copyright -->\n","protected":false},"excerpt":{"rendered":"<p>Signals Signals are a way of sending simple messages to processes. Most of these messages are already defined and can be found in <linux\/signal.h>. However, signals can only be processed when the process is in user mode. If a signal … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=437\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-437","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/437","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=437"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/437\/revisions"}],"predecessor-version":[{"id":703,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/437\/revisions\/703"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}