Signal Handling

[Srinivasan S_1]

Hi,

Is that, any program should handle such signals.

Like for example my program suppose to be kind of job program and needs to be stable. We have handled few signals.

a) Is that we need to handle all signals (ofcourse apart from not trappable) to keep it running stable?

b) Is that any guidelines that minimum of signals should be handled ?

Any pointer would be of great help.

[A. Clay Stephenson · Accepted solution]

There is really no need to handle all signals because most are not raised.

Generally, handling SIGHUP, SIGINT, SIGQUIT, and SIGTERM will suffice but that depends upon what your program actually does.

[Amit Agarwal_1]

I don't know of any guidelines, but by looking at your requirements I would suggest to block the signals which causes process termination by default. Ofcourse as you already said, you cannot trap SIGKILL.

For the other signals, you can be little choosy. See 'man 5 signal' for list of signals.

[HGN]

Hi

I have not seen any scripts for sinal handling,this depends on what signals you handled mostly it would be I think

SIGINT Terminal Interrupt
SIGABRT Process Abort
SIGQUIT Terminal Quit
SIGHUP Hangup

are some of them you could always look into the man pages for 5 signal

Rgds

HGN

[Stephen Keane]

Do you want to trap signals for a program written in say C, or a shell script? If we knew some more information we would be more helpful.

[Srinivasan S_1]

Thanks for all for replies.

Stephen Keane,
I am just looking for guidelines or "better programming practice" that such unix signals needs to be handled in general for any process (daemon or any continus running process like jobs)?

As my program needs to be more stable, if there is any chance that any stray program should not send signal that if not handled would exit.

[Stephen Keane]

As I said, a little more information would be helpful.

You might (depending on circumstances) wan't to trap and deal with SIGCHLD for example, or possibly SIGPIPE.

[A. Clay Stephenson]

There aren't any "stray" signals; moreover, normally any signals sent outside of a process'es process group (unless sent by root) are ignored. If you are writing daemons then a few extra steps are needed but probably the most important is a call to setsid() which has the effect of establishing a new process group. This means that no other processes can signal this process --- again unless root does it. The need to call setsid() is why it's difficult to write a good daemon in the shell although it is possible in Perl because setsid() is available.

You should also note that it may be perfectly normal for even a daemon to die on a SIGTERM, for example, but you want to make sure that the daemon dies gracefully after performing any needed cleanup tasks.