On Wed, 14 Apr 2004, Philip Hazel wrote:
> On Tue, 13 Apr 2004, A. Wik wrote:
>
> > The following address(es) have yet to be delivered:
> > user@???: smtp transport process returned non-zero status 0x000e: terminated by signal 14
>
> That is odd. Exim should be running with a signal handler enabled for
> SIGALRM; it sets this up right at the start of each Exim process. Thus,
> no process should ever be killed by SIGALRM.
>
> What operating system are you using?
The "uname -a" output is:
Linux decpc 2.4.18 #1 Wed Nov 13 19:56:49 GMT 2002 i586 unknown
libc is glibc-2.3.1.
> It is possible that the signal
> handler setting is not being preserved over fork()?
The fork() man page only mentions that pending signals are
not inherited.
But the signal() man page mentions some differences between
different operating systems and C-libraries:
The original Unix signal() would reset the handler to
SIG_DFL, and System V (and the Linux kernel and libc4,5)
does the same. On the other hand, BSD does not reset the
handler, but blocks new instances of this signal from
occurring during a call of the handler. The glibc2
library follows the BSD behaviour.
If one on a libc5 system includes <bsd/signal.h> instead
of <signal.h> then signal is redefined as __bsd_signal and
signal has the BSD semantics. This is not recommended.
If one on a glibc2 system defines a feature test macro
such as _XOPEN_SOURCE or uses a separate sysv_signal func-
tion, one obtains classical behaviour. This is not recom-
mended.
Trying to change the semantics of this call using defines
and includes is not a good idea. It is better to avoid
signal altogether, and use sigaction(2) instead.
-aw
