Re: [Exim] Frozen deferred messages

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: A. Wik
Dátum:  
Címzett: exim-users
Tárgy: Re: [Exim] Frozen deferred messages
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