Date: Sat, 18 Aug 2001 12:02:02 +0300 From: Valentin Nechayev <netch@iv.nn.kiev.ua> To: Hans Zaunere <zaunere@yahoo.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Signal Handling Message-ID: <20010818120202.A399@iv.nn.kiev.ua> In-Reply-To: <20010813160932.30924.qmail@web12801.mail.yahoo.com>; from zaunere@yahoo.com on Mon, Aug 13, 2001 at 09:09:32AM -0700 References: <20010813160932.30924.qmail@web12801.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mon, Aug 13, 2001 at 09:09:32, zaunere (Hans Zaunere) wrote about "Signal Handling":
> In a program that I am working on, I've decided to
> catch signal 15, which then calls execl() in the
> handler to reload the program from the on-disk binary.
> I am able to send it the signal, it reloads, and
> works fine. However I could not send the signal again
> and have the program respond. I then learned, with
> some help, that the signal needs to be unblocked after
> each call. It now works as intended.
Do you call execl() from signal handler? Or signal handler sets flag,
and main cycle calls execl() seeing this flag?
In first case (execl() from signal handler) it is natural that signal remains
blocked, AFAIU, unless SA_NODEFER flag is set for signal handler.
In latter one, please find place of explicit sigprocmask() call.
Crossing exec*(), kernel resets all signal handlers to their default values
(SIG_DFL), but doesn't change signal blocking mask. In any case, either on
first exec() or consequent ones, you should deal with signal mask: unblock
signals which should be unblocked, block which and when should be blocked.
On process initialization, you should explicitly unblock signal
after installing signal handler.
And, do _not_ use signal 15 (SIGTERM) for re-execing: you put process
in conflict with signal semantics. SIGTERM is used, e.g., by init(8)
to notify processes about sooner system shutdown, and process caught it
should perform graceful shutdown. For re-execing daemons, SIGHUP or SIGUSR1
is in tradition.
> 1) Why, in the first place, does a signal become
> blocked after it is recieved? Why does the kernel
> want to do this?
See above. I suppose most probable variant is that you call exec() from signal
handler. For signal handlers, reasonable default behavior is to block signal
being currently in handling, to avoid harmful handler nesting.
> 2) If a 10k binary is running, the signal is sent, and
> the program is reloaded from disk, but is 100k (or 1k
> even) how does the signal handling function get
> called, taking into account what Stevens says. Steven
> states that the sigmask remains for calls across exec,
> so wouldn't the wrong address to the handler function
> be used?
This is Stevens' theoretical considering before desribing real practice.
Real practice is described in man execve which says:
==={{{
Signals set to be ignored in the calling process are set to be ignored in
the new process. Signals which are set to be caught in the calling pro-
cess image are set to default action in the new process image. Blocked
signals remain blocked regardless of changes to the signal action. The
signal stack is reset to be undefined (see sigaction(2) for more informa-
tion).
===}}}
Of course, addresses of signal handlers make no sense for new binary,
and they are reset (to SIG_DFL, i.e. no userland handler).
But signal mask remains unchanged. This allows process to install its own
custom signal handlers before unblocking.
> 3) Is my using of exec, in fact, the best way to
> reload the program on the fly, from within itself?
> What would be the best, robust, way to do this in the
> future?
It fully depends on design of your program. You should interface correctly
with system, all other is up to you.
/netch
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010818120202.A399>