Making distributed development process, the inevitable encounter program ends abnormally, in general, an end of the distributed framework will return a return code, by the time the return code can roughly know what the reason is because the program exception quit.
Due to the distributed systems typically run on linux, so the return code of some distributed design framework would be associated with linux signal itself.
But the return code distributed framework generally has its own significance, except to say without knowing the meaning of the official premise, and by comparing the signal of linux, you can roughly know how, of course, the premise is more distributed framework and the return code is related to the linux signal, if the job in the design of linux did not even take into account the signal, you can not go to the association.
We assume that the return code distributed framework and Linux signal is associated.
1. The distributed signal frame associated with the return code and the linux
Correlation expression: 128 + signal = exit code, for example, such as the return code is 134, it is considered appropriate signal 6, i.e. SIGABRT, unexpected exception occurs resulting in the process means that the process is terminated within, another example 137, can be We consider a return code is 9, we all know is to kill the process kill -9 pid, 137 is the same, perhaps because the memory overrun was killed, also need to analyze specific, but can probably give you a feeling.
The signal 2.linux
The figure shows the common 64 signal, man 7 signal can also be used to view the specific meaning of the signal. Numbered from 1 to 31 as a signal of support for the traditional UNIX signal, the signal is not reliable (non-real), numbered 32 to 63 of the signal is later expanded, known as a reliable signal (real-time signal). The difference between reliable and unreliable signal signal is that the former does not support queue, may cause loss of signal, but not the latter.
For these signals, there are generally three treatments Linux way, ignored, capture and default actions:
- Ignore the signal, most of the signal may use this to deal with, but there are two signals can not be ignored (respectively
SIGKILLandSIGSTOP). Because they provide a reliable method to terminate the process and stop the kernel and super user, if ignored, then the process becomes no one can manage the process, obviously kernel designers do not want to see the scene - Capture signal, you need to tell the kernel, users want to do with a certain kind of signal, it means to write a signal handler, then this function will tell the kernel. When this signal is generated by the kernel calls the user-defined function, in order to achieve a certain signal processing.
- The default action for each signal, the system should have the default of the processing operation, when the signal occurs, the system automatically. However, for the system, most of the treatments are more brutal, it is to directly kill the process.
1) SIGHUP
This signal is connected to the user terminal (emitted at the end of normal or abnormal), typically at the end of the process control terminal, notifies each of the session in the same job, and this time they are no longer associated control terminal.
When you log Linux, the system will assign the user to a login terminal (Session). In the end all programs running, including background and foreground process group process group, generally belong to this Session. When the user exits Linux login, foreground and background process group have to process the output terminal will receive a SIGHUP signal. The default action of this signal is to terminate the process, and therefore have the background and the foreground process group process output terminal will be suspended. But it can capture the signal, such as wget can capture SIGHUP signal and ignore it, so even out of the Linux login, wget can continue to download.
In addition, the terminal from the daemon relations, this signal is used to inform it to reread its configuration file.
2) SIGINT
program termination (interrupt) signal is sent when the user types the INTR character (usually Ctrl-C), is used to notify the foreground process group to terminate the process.
3) SIGQUIT
and SIGINT similar, but the QUIT character (usually Ctrl- \) to control. In the process due to receipt of producing a core file SIGQUIT exit, similar to a program error signal in this sense.
4) SIGILL
performed an illegal instruction error usually occurs because the executable file itself, or try to perform a data segment. It is also possible to generate a stack overflow when this signal.
5) SIGTRAP
generated by a breakpoint instruction trap or other instructions used by the Debugger.
6) SIGABRT
call function signal generated abort.
7) SIGBUS
illegal address, memory address comprising alignment (Alignment) error. Such as access to a long integer words, but the address is not a multiple of 4. It differs from SIGSEGV is that the latter is due to the unauthorized access to the memory address of a legitimate trigger (such as access is not his own storage space or a read-only memory).
8) SIGFPE
issued at the time of the fatal arithmetic error occurs not only includes floating-point error also includes overflow and divide by zero all the other arithmetic and other errors.
9) SIGKILL
used to run the program immediately ends. This signal can not be blocked, and the processing is ignored. If the administrator can not find a process to terminate, you can try to send this signal.
10) SIGUSR1
left to the user to use
11) SIGSEGV
attempts to access its own memory not assigned to, or attempt to not have write access to the memory address to write data.
Signal 11, i.e., it may indicate the presence of illegal memory access program under certain conditions.
12) SIGUSR2
left to the user to use
13) SIGPIPE
pipe rupture. This signal is typically generated in the inter-process communication, such as using two processes FIFO (pipe) to communicate, read the pipeline did not go out into the open or terminated unexpectedly pipe write, write process will receive a SIGPIPE signal. Also with two processes Socket Communications, the writing process when writing the Socket, the reading process has been terminated.
14) SIGALRM
clock timing signals, calculating the actual time or clock time. Alarm function using the signal.
15) SIGTERM
program end (Terminate) signal, and SIGKILL except that the signal can be blocked and processed. Often used to ask an application exits normally, shell command kill default generate this signal. If the process is not terminated, we will try SIGKILL.
17) SIGCHLD
at the end of the child, the parent will receive the signal.
If the parent does not handle this signal, there is no wait (wait) the child, although the child process to terminate, but also possession of entries in the kernel process table, then the child process is called a zombie process. In this case we should avoid (the parent process or ignore SIGCHILD signal, or capturing it, or wait it derived the child, or parent process to terminate, then the child process to terminate automatically be taken over by the init process).
18) SIGCONT
make a stop (stopped) process continues. This signal can not be blocked. May use a handler to let the program accomplish a specific task when stopped by the state to continue. For example, the prompt is displayed again
19) SIGSTOP
stop executing (stopped) process and pay attention to the difference between it and terminate the interrupt: The process is not over, just suspend the implementation of this signal can not be blocked, processed or ignored.
20) SIGTSTP
stop running process, but the signal can be processed and ignored. This signal is sent when the user types the SUSP character (usually Ctrl-Z)
21) SIGTTIN
when a background job from the user terminal to read data, all processes in the job will receive SIGTTIN signal. The process will stop execution by default.
22) SIGTTOU
similar SIGTTIN, but received at the write terminal (terminal mode or modified).
23) SIGURG
the "urgent" data or out-of-band data is generated when reaching the socket.
24) SIGXCPU
exceeds CPU time limit. This limit can be read / changed by getrlimit / setrlimit.
25) SIGXFSZ
when the process attempted to expand the file so that the file size exceeds the resource limit.
26) SIGVTALRM
virtual clock signals similar to SIGALRM, but the process is calculated CPU time.
27) SIGPROF
similar SIGALRM / SIGVTALRM, but the process by including CPU time and time system calls.
28) SIGWINCH
made when the window size is changed.
29) SIGIO
file descriptor is ready to start for input / output operations.
30) SIGPWR
Power failure
31) SIGSYS
illegal system call.