Mailing List Archive

Changes in the daemon startup code, fd's not properly closed?
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.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Changes in the daemon startup code, fd's not properly closed? [ In reply to ]
On 3/1/2005 14:19, "Marc Haber" <mh+exim-dev@zugschlus.de> 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
Re: Changes in the daemon startup code, fd's not properly closed? [ In reply to ]
On Tue, Mar 01, 2005 at 02:53:47PM -0800, John W. Baxter wrote:
> 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.

If the processes get stuck, I can see exim's stdin, stdout, stderr
open to /dev/null just fine. The pipe to the debconf process which
prevents it from exiting ist something else.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Changes in the daemon startup code, fd's not properly closed? [ In reply to ]
On Tue, Mar 01, 2005 at 11:19:26PM +0100, Marc Haber wrote:
> The issue can be reproduced with a 4.50 daemon, but doesn't happen
> with a 4.44 daemon.

I have done a few more tests, including having the init script invoke
a 4.44 binary instead of the 4.50 binary without doing any additional
changes on the system.

When 4.44 is invoked by the 4.50 init script, everything is fine.
After doing one (and only one) change, namely having the init script
invoke an identically configured 4.50 binary, the process hangs.
Changing back to 4.44 again works fine.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835