Re: [exim-dev] Changes in the daemon startup code, fd's not …

On 3/1/2005 14:19, "Marc Haber" <mh+exim-dev@???> wrote:

> Hi,
>
> I would like to inquire whether the daemon startup code has been
> changed in the process that led us from 4.44 to 4.50. I am
> experiencing the following issue:
>
> After reconfiguring a Debian package, the daemon is restarted. When
> that restart is happening, the Debconf frontend is still running which
> does funky things with the file descriptors.
>
> We now have the situation that the reconfiguration script never exits
> after restarting the daemon. The Debconf frontend stays around,
> waiting to read from a file descriptor associated with a pipe that
> seems to be connected to the newly started exim daemon. This happens
> independently of that new daemon doing SMTP listening, spawning queue
> runners or both.
>
> The issue can be reproduced with a 4.50 daemon, but doesn't happen
> with a 4.44 daemon.
>
> The relevant parts of Debconf and our scripts around Debconf and exim
> did not change. They're the same in both packages, so this leaves only
> the daemon to be responsible for this change in behavior.
>
> Can somebody more familiar with the actual exam code please take a
> look? Is it possible that a file descriptor that has been introduced
> with 4.50 is not properly closed when the daemon starts, or that a
> close operation that has been in place before has been lost during the
> 4.50 release process?
>
> I'd appreciate any hints and will happily deliver additional
> information on request.

I'm not someone experienced with the actual code, but change 4.50/75 seems
relevant:


75. A backgrounded daemon closed stdin/stdout/stderr on entry; this meant
that those file descriptors could be used for SMTP connections. If anything
wrote to stderr (the example that came up was "warn" in embedded Perl), it
could be sent to the SMTP client, causing chaos. The daemon now opens stdin,
stdout, and stderr to /dev/null when it puts itself into the background.


--John