G
George Potemkin
Guest
It’s the ancient topic but I’d like to check if there are any changes since it was discussed many years ago. Unfortunately the classic “Traps, Kills, Hung Users, Runaways And Other Psychos” article now is not available but the idea was to send the sequence of the signals in the following order: SIGUSR1 SIGINT SIGQUIT SIGTERM SIGHUP I guess the order can be explained by information from PROSIGTRACE: SIGINT is the only signal that “sets SOFT ctrl-c (via utssoftctlc ()). (4465)”. The other handled signals set “HARD ctrl-c” (no matter what it means). SIGINT and SIGQUIT are the only ones that “ignore while in unix escape. (4467)” The descriptions of SIGTERM and SIGHUP are identical. So should we spend the time and send SIGHUP if SIGTERM did not work? What about SIGALRM - the only one with “immediate: do not delay handling this signal. (4468)”? The signals with the property “drSigClient: Signal dispatch specific to CLIENT. (4427)”: SIGHUP SIGINT SIGQUIT SIGTRAP SIGPIPE SIGTERM So what about SIGTRAP and SIGPIPE? Article: How Progress interprets and handles kill Signals knowledgebase.progress.com/.../P67938 Signal Name: SIGPIPE Common Signal Number: 13 Considered by Progress: HANDLED Client Handling: 1) if writer wants to process broker pipe then return, 2) look for valid output stream to write broken pipe message 3) look for dead sub processes and attempt to close their file descriptors Server Handling: 1) IGNORED by forked process, 2) If screen exists perform some screen cleanup write message that signal received ** Pipe to subprocess has been broken. (140) PROGRESS intercepted a SIGPIPE signal. This could be the result of a premature termination of a program used in an INPUT/OUTPUT THROUGH statement, or the abnormal termination of a shell invoked by the UNIX statement. When the handled signals do not work and we are sure it’s safe to terminate a session then what’s better to use as an absolute last resort - one of the STANDARD fatal signals (like SIGFPE) or REALLY fatal signal (SIGKILL)? For example, some standard fatal signals write the appropriate message to the .lg file (if it is open when the signal is received): SIGILL - SYSTEM ERROR: Illegal instruction. (47) SIGBUS - SYSTEM ERROR: Bus error. (48) SIGFPE - SYSTEM ERROR: Floating point exception. (50) SIGSYS - SYSTEM ERROR: Illegal system call. (297) Is it the only advantage of the standard fatal signals compared to SIGKILL? Are there any side-effects of turning on PROSIGTRACE for all processes in production environment? The customer of our is often getting the hung sessions that can't be stopped by the handled signals. Their protrace files used to contain the following calls: _poll_sys [/usr/lib/hpux64/libc.so.1] _poll [/usr/lib/hpux64/libc.so.1] utPollMultiple [/usr/dlc/bin/_progres] rnCheckForEvents [/usr/dlc/bin/_progres] rnSocketSelect [/usr/dlc/bin/_progres] _poll_sys [/usr/lib/hpux64/libc.so.1] _poll [/usr/lib/hpux64/libc.so.1] sock_poll_ipv4 [/usr/dlc/bin/_progres] npp_poll [/usr/dlc/bin/_progres] WebGetEvent [/usr/dlc/bin/_progres] It looks like a session is waiting for a response from TCP socket opened by application itself. Are there any gentle ways to interrupt these waits?
Continue reading...
Continue reading...