UNIX for Dummies Questions & Answers

Hi,

What is the use of the signal -3 in kill command in unix?

I read the meaning and typical use of this signal in one of the Oreilly books as below.

Code:

Quit -- stop running (and dump core). Sent when you type CTRL-\.

what does the CTRL-\ command do? Is it the combination of CTRL and hyphen and backslash?

Thanks in advance.

as it says - kills the process and dumps the core:

e.g:

Code:

% sleep 1000
^\Quit (core dumped)
% file core
core:           ELF 32-bit MSB core file SPARC Version 1, from 'sleep'

( and it's it's just hold ctrl and hit \ )

HTH

Thanks Tytalus!!!

Should we press ctrl and \ along with the command " kill -3 <<PID>>"

ctrl \ if process is in foreground

kill -3 <pid> if you are referencing a process that is not under immediate control...

The SIGQUIT (signal number 3) is triggered when you either issue "kill -3" or press the keystroke matching "quit".

To see the key mappings for your terminal use stty.

Code:

stty -a

On many systems the default mapping for "quit" is "ctrl backslash". This is one keystroke using the ctrl key like a shift key.

The place to find the full list of signals varies according to the Operating System. The "stty -a" enquiry is pretty universal.

Can you elaborate more on this Tytalus? I have just executed the kill command and checked the below command to see the process

Code:

ps -ef | grep java

i did not see the same process id again. Hence i pressed ctrl and \ , but no go. However the process id appeared after some time. Am i in the right path?

Okay here we go. The long explanation. Other correspondants may wish to add more.

When you issue "kill -n" the value of "n" is a numeric representation of the "signal". The list of signal numbers and their meaning for your Operating System is always available ... but we don't know which O/S you have.


The "quit" control code (in you case ctrl \) can be typed at a keyboard to deliberately crash a foreground process which is running on your terminal at that time and then produce a core dump. This is why many administrators disable this control code in user sessions. Unless you are in a development environment the core dump is of no value.
When typed at a keyboard the "quit" control code has no effect whatsoever on background processes.

The "kill -3 <pid>" unix command sends the signal to the background process with Process Identity <pid> (or for that matter to a process running in foreground on a terminal other than your own) asking that process to stop immediately and dump core. Unless you are in a development environment the core dump has no value.
Be aware that a process can be written to ignore any signal (except signal 9).

Though stating the obvious you cannot issue a "kill" command on your own terminal to your own foreground process because you do not have a command prompt at the time.

Most administrators would actually issue "kill -15" (hangup) to a broken background process unless of course the process is a database application which requires a specific different signal. The hangup signal simulates pulling out the cable on a serial terminal and most well-written applications will close tidily.

Most administrators (and users) would issue ctrl/C (interrupt) to a foreground process to ask it to stop. Administrators often disable this key at unix level where it needed by the application or when they don't want users crashing applications and being presented with a unix command prompt.
The ctrl/C keystroke has a similar function in Microsoft MSDOS and just happened to like unix and CP/M when MSDOS first came out.

The unix shell "trap" command can be used to intercept signals (excluding signal 9) and this can be useful for invoking a cleanup procedure.


Beware: There is rarely ever a reason to issue "kill -9" to a process and it should never ever be issued to a database server or client unless perhaps you are already in dire straits and cannot shut a server down just prior to restoring your backup.
You will find in you research that some critical unix processes (like "inetd") respond to specific signals and restart themselves cleanly after re-reading parameter files. This convenience is rarely found in commercial applications.


Footnote: Some unix kernels have a very limited default maximum process number and can recycle Process IDs rather too quickly. It may be that this is what is happening to you? A commercial unix will need a kernel build to match the expected load and this will usually cause a substantial increase in the maximum value of a Process ID and therefore less frequent recycling of Process IDs.