[Exim] SIGCHLD - SIG_IGN errors under Linux

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Vallimar
Date:  
À: exim-users
Sujet: [Exim] SIGCHLD - SIG_IGN errors under Linux
I'm using the latest glibc RPM's from RedHat Rawhide and they, or
the Glibc maintainers, have started a campaign it seems to get people
to fix a coding 'mistake' of setting SIGCHLD to SIG_IGN. RedHat has
been updating their RPM's their rpm's, but since they haven't shipped
Exim in any form for some time, I doubt they are interested in looking
at this so I'll toss it at the Exim developers.

The error as shows up via syslog is this:
<pid> is the child process pid and changes.

* application bug: exim(<pid>) has SIGCHLD set to SIG_IGN but calls wait().
* (see the NOTES section of 'man 2 wait'). Workaround activated.

Now, the relevant 'man 2 wait' section I'll include below:

The Single Unix Specification describes a flag SA_NOCLDWAIT (not sup-
ported under Linux) such that if either this flag is set, or the action
for SIGCHLD is set to SIG_IGN then children that exit do not become
zombies and a call to wait() or waitpid() will block until all children
have exited, and then fail with errno set to ECHILD.

The original POSIX standard left the behaviour of setting SIGCHLD to
SIG_IGN unspecified. Later standards, including SUSv2 and POSIX
1003.1-2001 specify the behaviour just described as an XSI-compliance
option. Linux does not conform to the second of the two points just
described: if a wait() or waitpid() call is made while SIGCHLD is being
ignored, the call behaves just as though SIGCHLD were not being igored,
that is, the call blocks until the next child terminates and then
returns the PID and status of that child.

I did a check look over the code and see where it does this in child.c
and daemon.c. Not being a coder myself, I've no real clue how to repair
the situation myself. This warning does explain why I've always seen
exim child processes go into a zombie state for long periods of time
before finally dying though. Any chance a developer can repair this?
My log files will be extremely thankful if you can stop the flood of
these messages :p

I'm not subscribed to the list, so if you do create a patch, please
make sure to cc me so I might try it out.