topic Re: SIGNALS in Operating System - HP-UX

SIGNALS

Kapil_2 — Tue, 12 Mar 2002 03:49:35 GMT

How do we find out the function which is the default action (SIG_DFL) for a signal.
eg abort is the function which is called by default for signal SIGABRT.
How do we find it out for the other signals

Kapil

Re: SIGNALS

Kenny Chau — Tue, 12 Mar 2002 03:56:14 GMT

Maybe this document will help you:

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90697/B2355-90697_top.html&con=/hpux/onlinedocs/B2355-90697/00/00/76-con.html&toc=/hpux/onlinedocs/B2355-90697/00/00/76-toc.html&searchterms=signal&queryid=20020311-195914

Or you can man the signal for information.

Hope this helps.
Kenny.

Re: SIGNALS

Steven Gillard_2 — Tue, 12 Mar 2002 10:18:51 GMT

Run "man 5 signal" to view the signal(5) man page. It has a table containing that information.

Regards,
Steve

Re: SIGNALS

Peter Kloetgen — Tue, 12 Mar 2002 10:25:57 GMT

Hi,

the command: kill -l lists you the signals, and to find the explanation for the signals, use the manpage:
man 5 signal
you will find a table with all signals and explanation for them here.

Allways stay on the bright side of life!

Peter

Re: SIGNALS

steven Burgess_2 — Tue, 12 Mar 2002 11:43:28 GMT

You can also enter stty -a to see what keyboard patterns perform particular functions.

You can assign new values to these also

stty

Re: SIGNALS

Kapil_2 — Mon, 18 Mar 2002 03:58:52 GMT

That was helpful
Now a few signals have the default action as terminate while a few have terminate with core file.
For termination the _exit is called.
Which function is called to generate the core file?

Also what exactly happens when signals are received whose default action is to ignore the signal and whose action is set to SIG_IGN as there is a slight difference in the two. eg SIGCHLD.

Kapil

Re: SIGNALS

Wodisch — Mon, 18 Mar 2002 17:48:32 GMT

Hello,

since you mention SIGCHLD, it really is different from most of the rest:
usually if a process starts a child process (system-call "fork"), and then (later on) the child process exits, this child process sends signal SGICHLD to its parent, in case the parent waits for it (system-call "wait"). The child-process in tunr waits for its parent to receive that signal (and get pu-time afterwards) and then vanishes (until then its in state "zombie", which is NOT bad).
This is the default behaviour, and hence different from SIG_DFLT (read: the parent does NOT die).
But if the parent (the to-be-parent) ignores the signal SIGCHLD *before* forking the the child, then the signal SIGCHLD is NOT sent from child to parent, and hence the child does enter the state "zombie". But then, that way the parent cannot "wait" for the child's exit!

HTH,
Wodisch

Re: SIGNALS

Kapil_2 — Thu, 18 Apr 2002 13:10:47 GMT

Hi Wodisch
So in the default action(ignore the signal) of SIGCHLD, it is still delivered to the parent(only when it enters the wait system call)?

Kapil

Re: SIGNALS

Steven Gillard_2 — Thu, 18 Apr 2002 13:59:57 GMT

The exit(2) man page describes what happens in this case:

"If the parent process of the calling process is not executing a wait(), wait3(), or waitpid(), and does not have SIGCLD set to SIG_IGN, the calling process is transformed into a zombie process. A zombie process is a process that only occupies a slot in the process table. It has no other space allocated either in user or kernel space."

And from signal(5):

"Setting the action for SIGCLD to SIG_IGN in a parent process prevents exiting children of the calling process from creating a zombie process. If the parent process executes the wait() function, the calling process blocks until all of the child processes of the calling processes terminate. The wait() function then returns a value of -1 with errno set to ECHILD (see wait(2) )."

So, if a parent is ignoring SIGCLD and not wait()ing for its children then they simply die without entering the zombie state and the parent will never be able to receive the status information. The SIGCLD signal is still delivered, but is ignored.

Put another way, a parent process can only receive status information from dying children if it either:

1. Installs a handler for SIGCHLD that calls one of the wait*() system calls upon receipt of the signal.

2. Blocks in one of the wait*() system calls until the child dies.

Hope this makes sense.

Regards,
Steve

Re: SIGNALS

Kapil_2 — Mon, 22 Apr 2002 13:40:43 GMT

Hi Steven,
How does the child know if the SIGCHLD in the parent is set to default or SIG_IGN, which would help it remain zombie or not?
Does the wait() system call get the status of the process after getting the SIGCHLD from the child or does it scan the process table for zombie entries?

Kapil

Re: SIGNALS

Steven Gillard_2 — Mon, 22 Apr 2002 18:11:18 GMT

>>How does the child know if the SIGCHLD in the parent is set to default or SIG_IGN, which would help it remain zombie or not?

This is handled by the kernel during its processing of the exit() system call in the child. The child does not 'know' if the parent is ignoring SIGCHLD or not.

>>Does the wait() system call get the status of the process after getting the SIGCHLD from the child or does it scan the process table for zombie entries?

Yes, the wait() system call simply returns the exit status of the zombie child and allows its entry to be removed from the process table. If the parent does not call wait() after receiving a SIGCHLD then the child will remain a zombie as long as the parent lives. This I would call a bug in the parent code.

Regards,
Steve