dpkg-reconfigure exim4-config hangs, blocks debian installation

[Debian Bug Importer]

Automatically imported from Debian bug report #297607 http://bugs.debian.org/297607

[Marc Haber (mh+debian-packages)]

On Tue, Mar 01, 2005 at 01:20:40PM -0500, Joey Hess wrote:
> Package: exim4-config
> Version: 4.50-2
> Severity: grave
> Justification: breaks debian installation

yuck!

> base-config runs a dpkg-reconfigure exim4-config as part of the Debian
> installation process so users get a chance to configure exim, which is
> initially installed noninteractively by debootstrap.
>
> With this new version now in unstable, I've noticed that my all my daily
> debian automatic installation tests of unstable installs have begin to
> fail, because the dpkg-reconfigure run hangs after the questions are
> asked. This is easy to reproduce:
>
> cow:/home/joey# dpkg-reconfigure exim4-config
> Restarting MTA: exim4.

Does 4.44 from sarge, or the old 4.34 from last week's sarge work on
this system?

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

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #297607 http://bugs.debian.org/297607

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 1 Mar 2005 13:20:40 -0500
From: Joey Hess <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: dpkg-reconfigure exim4-config hangs, blocks debian installation

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Package: exim4-config
Version: 4.50-2
Severity: grave
Justification: breaks debian installation

base-config runs a dpkg-reconfigure exim4-config as part of the Debian
installation process so users get a chance to configure exim, which is
initially installed noninteractively by debootstrap.

With this new version now in unstable, I've noticed that my all my daily
debian automatic installation tests of unstable installs have begin to
fail, because the dpkg-reconfigure run hangs after the questions are
asked. This is easy to reproduce:

cow:/home/joey# dpkg-reconfigure exim4-config
Restarting MTA: exim4.

It will never return to the prompt. ps shows this:

 4547 pts/1 S+ 0:01 | \_ /usr/bin/perl -w /usr/sb=
in/dp
 4554 pts/1 Z+ 0:00 | \_ [exim4-config.] <def=
unct>

Strace of the debconf process (4547) shows it blocked in read from fd 8:

cow:/home/joey# strace -p 4547
Process 4547 attached - interrupt to quit
read(8,=20

I assume this is some sort of debconf/daemon interaction problem. The proce=
ss
tree also has an exim daemon running at this point. If I kill it, deconf st=
ops
blocking and returns. Presumably the code that runs this daemon no longer
takes care to close file descriptors connected to debconf.

FWIW, this system has debconf 1.4.46 installed.=20

--=20
see shy jo

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCJLJ3d8HHehbQuO8RArKjAJ96Fk96muVF/InZLPYOmC4sKjR3qwCfTolb
1vsm4OkW99ZR/YNFhaG0KcM=
=4Ccq
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 1 Mar 2005 19:42:56 +0100
From: Marc Haber <email address hidden>
To: Joey Hess <email address hidden>, <email address hidden>
Cc: Marc Haber <email address hidden>
Subject: Re: dpkg-reconfigure exim4-config hangs, blocks debian installation

On Tue, Mar 01, 2005 at 01:20:40PM -0500, Joey Hess wrote:
> Package: exim4-config
> Version: 4.50-2
> Severity: grave
> Justification: breaks debian installation

yuck!

> base-config runs a dpkg-reconfigure exim4-config as part of the Debian
> installation process so users get a chance to configure exim, which is
> initially installed noninteractively by debootstrap.
>
> With this new version now in unstable, I've noticed that my all my daily
> debian automatic installation tests of unstable installs have begin to
> fail, because the dpkg-reconfigure run hangs after the questions are
> asked. This is easy to reproduce:
>
> cow:/home/joey# dpkg-reconfigure exim4-config
> Restarting MTA: exim4.

Does 4.44 from sarge, or the old 4.34 from last week's sarge work on
this system?

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

[Matt Zimmerman (mdz)]

Regression in Debian

[Joey Hess (joeyh)]

Marc Haber wrote:
> On Tue, Mar 01, 2005 at 01:20:40PM -0500, Joey Hess wrote:
> > Package: exim4-config
> > Version: 4.50-2
> > Severity: grave
> > Justification: breaks debian installation
>
> yuck!
>
> > base-config runs a dpkg-reconfigure exim4-config as part of the Debian
> > installation process so users get a chance to configure exim, which is
> > initially installed noninteractively by debootstrap.
> >
> > With this new version now in unstable, I've noticed that my all my daily
> > debian automatic installation tests of unstable installs have begin to
> > fail, because the dpkg-reconfigure run hangs after the questions are
> > asked. This is easy to reproduce:
> >
> > cow:/home/joey# dpkg-reconfigure exim4-config
> > Restarting MTA: exim4.
>
> Does 4.44 from sarge, or the old 4.34 from last week's sarge work on
> this system?

Yes, 4.44-2 is ok. (Btw, I'm seeing it on at least 4 architectures, have
not checked the rest.)

--
see shy jo

[Joey Hess (joeyh)]

# Automatically generated email from bts, devscripts version 2.8.10
tags 297607 sid

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 1 Mar 2005 14:22:40 -0500
From: Joey Hess <email address hidden>
To: Marc Haber <email address hidden>
Cc: <email address hidden>
Subject: Re: dpkg-reconfigure exim4-config hangs, blocks debian installation

--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Marc Haber wrote:
> On Tue, Mar 01, 2005 at 01:20:40PM -0500, Joey Hess wrote:
> > Package: exim4-config
> > Version: 4.50-2
> > Severity: grave
> > Justification: breaks debian installation
>=20
> yuck!
>=20
> > base-config runs a dpkg-reconfigure exim4-config as part of the Debian
> > installation process so users get a chance to configure exim, which is
> > initially installed noninteractively by debootstrap.
> >=20
> > With this new version now in unstable, I've noticed that my all my daily
> > debian automatic installation tests of unstable installs have begin to
> > fail, because the dpkg-reconfigure run hangs after the questions are
> > asked. This is easy to reproduce:
> >=20
> > cow:/home/joey# dpkg-reconfigure exim4-config
> > Restarting MTA: exim4.
>=20
> Does 4.44 from sarge, or the old 4.34 from last week's sarge work on
> this system?

Yes, 4.44-2 is ok. (Btw, I'm seeing it on at least 4 architectures, have
not checked the rest.)

--=20
see shy jo

--ZGiS0Q5IWpPtfppv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCJMEAd8HHehbQuO8RAif6AJ908xhepix4sXTfJPbFJCGskTvdfQCfblCU
gQY65nGnluNHx+440tFLGuo=
=zGV6
-----END PGP SIGNATURE-----

--ZGiS0Q5IWpPtfppv--

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 1 Mar 2005 14:22:50 -0500
From: Joey Hess <email address hidden>
To: <email address hidden>
Subject: tagging 297607

# Automatically generated email from bts, devscripts version 2.8.10
tags 297607 sid

[Marc Haber (mh+debian-packages)]

tags #297607 confirmed
thanks

On Tue, Mar 01, 2005 at 02:22:40PM -0500, Joey Hess wrote:
> Marc Haber wrote:
> > Does 4.44 from sarge, or the old 4.34 from last week's sarge work on
> > this system?
>
> Yes, 4.44-2 is ok.

I confirm the issue existing with 4.50, can reproduce it here. If I
interpret correctly, the fd that the debconf frontend stalls reading
from is connected to the exim daemon.

Hm. The Debconf-related stuff did not change besides cosmetics between
4.44-2 and 4.50-3. But I have seen that we do quite unusual stuff,
such as restarting the daemon in the .config script, which seems to be
rather exotic.

I'll consult with the other Exim 4 maintainers and upstream, and would
appreciate any debugging help.

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 1 Mar 2005 23:06:06 +0100
From: Marc Haber <email address hidden>
To: Joey Hess <email address hidden>, <email address hidden>
Cc: Marc Haber <email address hidden>
Subject: Re: Bug#297607: dpkg-reconfigure exim4-config hangs, blocks debian installation

tags #297607 confirmed
thanks

On Tue, Mar 01, 2005 at 02:22:40PM -0500, Joey Hess wrote:
> Marc Haber wrote:
> > Does 4.44 from sarge, or the old 4.34 from last week's sarge work on
> > this system?
>
> Yes, 4.44-2 is ok.

I confirm the issue existing with 4.50, can reproduce it here. If I
interpret correctly, the fd that the debconf frontend stalls reading
from is connected to the exim daemon.

Hm. The Debconf-related stuff did not change besides cosmetics between
4.44-2 and 4.50-3. But I have seen that we do quite unusual stuff,
such as restarting the daemon in the .config script, which seems to be
rather exotic.

I'll consult with the other Exim 4 maintainers and upstream, and would
appreciate any debugging help.

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

[Marc Haber (mh+debian-packages)]

Source: exim4
Source-Version: 4.50-4

We believe that the bug you reported is fixed in the latest version of
exim4, which is due to be installed in the Debian FTP archive:

exim4-base_4.50-4_i386.deb
  to pool/main/e/exim4/exim4-base_4.50-4_i386.deb
exim4-config_4.50-4_all.deb
  to pool/main/e/exim4/exim4-config_4.50-4_all.deb
exim4-daemon-heavy_4.50-4_i386.deb
  to pool/main/e/exim4/exim4-daemon-heavy_4.50-4_i386.deb
exim4-daemon-light_4.50-4_i386.deb
  to pool/main/e/exim4/exim4-daemon-light_4.50-4_i386.deb
exim4_4.50-4.diff.gz
  to pool/main/e/exim4/exim4_4.50-4.diff.gz
exim4_4.50-4.dsc
  to pool/main/e/exim4/exim4_4.50-4.dsc
exim4_4.50-4_all.deb
  to pool/main/e/exim4/exim4_4.50-4_all.deb
eximon4_4.50-4_i386.deb
  to pool/main/e/exim4/eximon4_4.50-4_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marc Haber <email address hidden> (supplier of updated exim4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 2 Mar 2005 07:38:52 +0000
Source: exim4
Binary: eximon4 exim4-daemon-custom exim4-daemon-heavy exim4-base exim4 exim4-daemon-light exim4-config
Architecture: source i386 all
Version: 4.50-4
Distribution: unstable
Urgency: low
Maintainer: Exim4 Maintainers <email address hidden>
Changed-By: Marc Haber <email address hidden>
Description:
 exim4 - metapackage to ease exim MTA (v4) installation
 exim4-base - support files for all exim MTA (v4) packages
 exim4-config - configuration for the exim MTA (v4)
 exim4-daemon-heavy - exim MTA (v4) daemon with extended features, including exiscan-ac
 exim4-daemon-light - lightweight exim MTA (v4) daemon
 eximon4 - monitor application for the exim MTA (v4) (X11 interface)
Closes: 297607
Changes:
 exim4 (4.50-4) unstable; urgency=low
 .
   * fix 10_daemon_close_fds.dpatch to actually apply again. Sheesh.
     Thanks to Joey Hess. (mh) Closes: #297607
Files:
 a73c8b529e258aaa4e55064af2983326 1057 mail important exim4_4.50-4.dsc
 7a39fc0ace7ba24fcbde22b45f175e86 477122 mail important exim4_4.50-4.diff.gz
 2ab8223091bc6ee17c587ba7491acae4 810100 mail important exim4-base_4.50-4_i386.deb
 eaa54faea580a677084696e62a6b9276 366322 mail important exim4-daemon-light_4.50-4_i386.deb
 fb3a2b302ae1b3c4fa78c1195c956973 75626 mail optional eximon4_4.50-4_i386.deb
 6f9ef2b25cf67b16429bb3048a1795c4 416806 mail optional exim4-daemon-heavy_4.50-4_i386.deb
 c3f8d18719b0527bbe9c55fd812e37a9 223202 mail important exim4-config_4.50-4_all.deb
 a9faae05178e87186ed71e98ffddd0e6 1820 mail important exim4_4.50-4_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iEYEARECAAYFAkIlcQoACgkQgZalRGu6PITgkACfVklCXUIJ6lS0GLVQIGyiQU3F
vF4AoLdz/dmmi7j9oBqvj5p4rJEWXj...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 02 Mar 2005 03:02:11 -0500
From: Marc Haber <email address hidden>
To: <email address hidden>
Subject: Bug#297607: fixed in exim4 4.50-4

Source: exim4
Source-Version: 4.50-4

We believe that the bug you reported is fixed in the latest version of
exim4, which is due to be installed in the Debian FTP archive:

exim4-base_4.50-4_i386.deb
  to pool/main/e/exim4/exim4-base_4.50-4_i386.deb
exim4-config_4.50-4_all.deb
  to pool/main/e/exim4/exim4-config_4.50-4_all.deb
exim4-daemon-heavy_4.50-4_i386.deb
  to pool/main/e/exim4/exim4-daemon-heavy_4.50-4_i386.deb
exim4-daemon-light_4.50-4_i386.deb
  to pool/main/e/exim4/exim4-daemon-light_4.50-4_i386.deb
exim4_4.50-4.diff.gz
  to pool/main/e/exim4/exim4_4.50-4.diff.gz
exim4_4.50-4.dsc
  to pool/main/e/exim4/exim4_4.50-4.dsc
exim4_4.50-4_all.deb
  to pool/main/e/exim4/exim4_4.50-4_all.deb
eximon4_4.50-4_i386.deb
  to pool/main/e/exim4/eximon4_4.50-4_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marc Haber <email address hidden> (supplier of updated exim4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 2 Mar 2005 07:38:52 +0000
Source: exim4
Binary: eximon4 exim4-daemon-custom exim4-daemon-heavy exim4-base exim4 exim4-daemon-light exim4-config
Architecture: source i386 all
Version: 4.50-4
Distribution: unstable
Urgency: low
Maintainer: Exim4 Maintainers <email address hidden>
Changed-By: Marc Haber <email address hidden>
Description:
 exim4 - metapackage to ease exim MTA (v4) installation
 exim4-base - support files for all exim MTA (v4) packages
 exim4-config - configuration for the exim MTA (v4)
 exim4-daemon-heavy - exim MTA (v4) daemon with extended features, including exiscan-ac
 exim4-daemon-light - lightweight exim MTA (v4) daemon
 eximon4 - monitor application for the exim MTA (v4) (X11 interface)
Closes: 297607
Changes:
 exim4 (4.50-4) unstable; urgency=low
 .
   * fix 10_daemon_close_fds.dpatch to actually apply again. Sheesh.
     Thanks to Joey Hess. (mh) Closes: #297607
Files:
 a73c8b529e258aaa4e55064af2983326 1057 mail important exim4_4.50-4.dsc
 7a39fc0ace7ba24fcbde22b45f175e86 477122 mail important exim4_4.50-4.diff.gz
 2ab8223091bc6ee17c587ba7491acae4 810100 mail important exim4-base_4.50-4_i386.deb
 eaa54faea580a677084696e62a6b9276 366322 mail important exim4-daemon-light_4.50-4_i386.deb
 fb3a2b302ae1b3c4fa78c1195c956973 75626 mail optional eximon4_4.50-4_i386.deb
 6f9ef2b25cf67b16429bb3048a1795c4 416806 mail optional exim4-daemon-heavy_4.50-4_i386.deb
 c3f8d18719b0527bbe9c55fd812e37a9 223202 mail important exim4-config_4.50-4_all.deb
 a9faae05178e87186e...

[Marc Haber (mh+debian-packages)]

reopen #297607
tags #297607 -sid
severity #297607 normal
thanks

On Wed, Mar 02, 2005 at 03:02:11AM -0500, Marc Haber wrote:
> * fix 10_daemon_close_fds.dpatch to actually apply again. Sheesh.
> Thanks to Joey Hess. (mh) Closes: #297607

I am afraid that we'll have to back out that patch as it is a likely
cause for #299051 and probable #297174.

Can you please give the inofficial 4.50-4.0 from
http://zg.debian.zugschlus.de/zg/pool/main/exim4 a try before I upload
to unstable and probably cause _more_ breakage?

Grüße
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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 12 Mar 2005 00:14:47 +0100
From: Marc Haber <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Patch causes other breakage

reopen #297607
tags #297607 -sid
severity #297607 normal
thanks

On Wed, Mar 02, 2005 at 03:02:11AM -0500, Marc Haber wrote:
> * fix 10_daemon_close_fds.dpatch to actually apply again. Sheesh.
> Thanks to Joey Hess. (mh) Closes: #297607

I am afraid that we'll have to back out that patch as it is a likely
cause for #299051 and probable #297174.

Can you please give the inofficial 4.50-4.0 from
http://zg.debian.zugschlus.de/zg/pool/main/exim4 a try before I upload
to unstable and probably cause _more_ breakage?

Gr�rc

--
-----------------------------------------------------------------------------
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

[Frans Pop (aragorn)]

Hello Marc,

On Sunday 20 March 2005 15:44, Marc Haber wrote:
> This is a formal request to test whether the exim4 4.50-4.0
> downloadable from http://zg.debian.zugschlus.de/zg/pool/main/exim4 do
> any harm to d-i. Please test and inform me of any results.
>
> If I don't receive an answer by thursday 2005-03-24, I'll consider
> this as "everything is fine" and will proceed uploading to unstable.

A day late, but your request got a bit lost in the efforts to release
RC3...

I tried integrating the new debs in the installation as much as possible
by chrooting into the target system after base installation (debootstrap)
and installing the debs with the noninteractive frontend.
This means that exim4 was configured after the reboot as normal during
installation.

I noticed no problems during the installation or configuration in 2nd
stage itself.

The only thing I did notice is that, if I run 'dpkg-reconfigure
exim4-config' _after_ the installation is completed, "restarting MTA"
takes a very long time (something like 30 seconds), but only the first
time I do it. If I try to reproduce it later, the restart consistently
only takes 4 or 5 seconds.
During recent normal installations from Sarge (on different archs), I've
seen a similar problem: on the first shutdown after installation it takes
a very long time to "stop MTA".
I have no idea what could cause this.

Tested on i386 using:
ii exim4 4.50-4.0 metapackage to ease exim MTA (v4) installati
ii exim4-base 4.50-4.0 support files for all exim MTA (v4) packages
ii exim4-config 4.50-4.0 configuration for the exim MTA (v4)
ii exim4-daemon-l 4.50-4.0 lightweight exim MTA (v4) daemon

Cheers,
FJP

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sat, 26 Mar 2005 00:13:45 +0100
From: Frans Pop <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: Marc Haber <email address hidden>
Subject: Re: exim4 prone to break d-i, bug #297607

--nextPart3960424.JM9qiAzsdU
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Marc,

On Sunday 20 March 2005 15:44, Marc Haber wrote:
> This is a formal request to test whether the exim4 4.50-4.0
> downloadable from http://zg.debian.zugschlus.de/zg/pool/main/exim4 do
> any harm to d-i. Please test and inform me of any results.
>
> If I don't receive an answer by thursday 2005-03-24, I'll consider
> this as "everything is fine" and will proceed uploading to unstable.

A day late, but your request got a bit lost in the efforts to release=20
RC3...

I tried integrating the new debs in the installation as much as possible=20
by chrooting into the target system after base installation (debootstrap)=20
and installing the debs with the noninteractive frontend.
This means that exim4 was configured after the reboot as normal during=20
installation.

I noticed no problems during the installation or configuration in 2nd=20
stage itself.

The only thing I did notice is that, if I run 'dpkg-reconfigure=20
exim4-config' _after_ the installation is completed, "restarting MTA"=20
takes a very long time (something like 30 seconds), but only the first=20
time I do it. If I try to reproduce it later, the restart consistently=20
only takes 4 or 5 seconds.
During recent normal installations from Sarge (on different archs), I've=20
seen a similar problem: on the first shutdown after installation it takes=20
a very long time to "stop MTA".
I have no idea what could cause this.

Tested on i386 using:
ii exim4 4.50-4.0 metapackage to ease exim MTA (v4) installati
ii exim4-base 4.50-4.0 support files for all exim MTA (v4) packages
ii exim4-config 4.50-4.0 configuration for the exim MTA (v4)
ii exim4-daemon-l 4.50-4.0 lightweight exim MTA (v4) daemon

Cheers,
=46JP

--nextPart3960424.JM9qiAzsdU
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCRJsqgm/Kwh6ICoQRAvlGAKDQ2ZXrvtlBPCyhbjcDrSQVoNGt7gCgt5K7
bD9JwsmVd+sWxFeZwe5dLLI=
=juij
-----END PGP SIGNATURE-----

--nextPart3960424.JM9qiAzsdU--

[Marc Haber (mh+debian-packages)]

Hi Frans,

thanks for testing.

On Sat, Mar 26, 2005 at 12:13:45AM +0100, Frans Pop wrote:
> I tried integrating the new debs in the installation as much as possible
> by chrooting into the target system after base installation (debootstrap)
> and installing the debs with the noninteractive frontend.
> This means that exim4 was configured after the reboot as normal during
> installation.
>
> I noticed no problems during the installation or configuration in 2nd
> stage itself.

Good.

The original bug surfaced in joeyh's regression testing installations
and could be reproduced in a normal system.

> The only thing I did notice is that, if I run 'dpkg-reconfigure
> exim4-config' _after_ the installation is completed, "restarting MTA"
> takes a very long time (something like 30 seconds), but only the first
> time I do it.

That sounds like a DNS issue. Exim tries to resolve its own hostname,
and if that cannot be done, it waits for a DNS timeout. Usual remedy
is making sure that the local hostname (hostname _and_ FQDN) is
resolvable via /etc/hosts, since for a new install the hostname is
unlikely to be available via DNS. See the second FAQ question in
README.Debian

> If I try to reproduce it later, the restart consistently
> only takes 4 or 5 seconds.
> During recent normal installations from Sarge (on different archs), I've
> seen a similar problem: on the first shutdown after installation it takes
> a very long time to "stop MTA".

That's a new one. Can you try setting EX4DEBUG to a non-empty value
and see where the delay is happening?

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 26 Mar 2005 06:47:42 +0100
From: Marc Haber <email address hidden>
To: Frans Pop <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: exim4 prone to break d-i, bug #297607

Hi Frans,

thanks for testing.

On Sat, Mar 26, 2005 at 12:13:45AM +0100, Frans Pop wrote:
> I tried integrating the new debs in the installation as much as possible
> by chrooting into the target system after base installation (debootstrap)
> and installing the debs with the noninteractive frontend.
> This means that exim4 was configured after the reboot as normal during
> installation.
>
> I noticed no problems during the installation or configuration in 2nd
> stage itself.

Good.

The original bug surfaced in joeyh's regression testing installations
and could be reproduced in a normal system.

> The only thing I did notice is that, if I run 'dpkg-reconfigure
> exim4-config' _after_ the installation is completed, "restarting MTA"
> takes a very long time (something like 30 seconds), but only the first
> time I do it.

That sounds like a DNS issue. Exim tries to resolve its own hostname,
and if that cannot be done, it waits for a DNS timeout. Usual remedy
is making sure that the local hostname (hostname _and_ FQDN) is
resolvable via /etc/hosts, since for a new install the hostname is
unlikely to be available via DNS. See the second FAQ question in
README.Debian

> If I try to reproduce it later, the restart consistently
> only takes 4 or 5 seconds.
> During recent normal installations from Sarge (on different archs), I've
> seen a similar problem: on the first shutdown after installation it takes
> a very long time to "stop MTA".

That's a new one. Can you try setting EX4DEBUG to a non-empty value
and see where the delay is happening?

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

[Frans Pop (aragorn)]

On Saturday 26 March 2005 06:47, Marc Haber wrote:
> > The only thing I did notice is that, if I run 'dpkg-reconfigure
> > exim4-config' _after_ the installation is completed, "restarting MTA"
> > takes a very long time (something like 30 seconds), but only the
> > first time I do it.
>
> That sounds like a DNS issue. Exim tries to resolve its own hostname,
> and if that cannot be done, it waits for a DNS timeout. Usual remedy
> is making sure that the local hostname (hostname _and_ FQDN) is
> resolvable via /etc/hosts, since for a new install the hostname is
> unlikely to be available via DNS. See the second FAQ question in
> README.Debian

No, that's not it. Both systems are known on my DNS server. It could still
well be a DNS issue, but nothing that easy.

> > During recent normal installations from Sarge (on different archs),
> > I've seen a similar problem: on the first shutdown after installation
> > it takes a very long time to "stop MTA".
>
> That's a new one. Can you try setting EX4DEBUG to a non-empty value
> and see where the delay is happening?

I've reproduced it just now during an installation using the sparc64 RC3
netinst CD. The pause during power off is at the "start-stop-daemon
--stop" command.
The pause is about the same as when exim is being restarted during
reconfiguration in the first situation.

During previous installations with "local mail only", the default for the
hostname would mostly be the system name. Now I see
"localhost.localdomain" in some (all?) installations. Could that be the
root cause for both these issues?

This could be something from the d-i installation.
On this new Sparc installation I get in /etc/hosts (DHCP with fixed
address):
127.0.0.1 localhost.localdomain localhost gimli

On another installation I have:
127.0.0.1 localhost.localdomain localhost
10.19.66.2 elrond.fjphome.nl elrond

So on the new install the FQN is missing in /etc/hosts, but it is also
readily supplied by my DNS server:
fjp@gimli:~$ ping gimli.fjphome.nl
PING gimli.fjphome.nl (10.19.66.9) 56(84) bytes of data.
64 bytes from gimli.fjphome.nl (10.19.66.9): icmp_seq=1 ttl=64 time=0.273
ms
64 bytes from gimli.fjphome.nl (10.19.66.9): icmp_seq=2 ttl=64 time=0.083
ms

Would you like me to file a separate BR for this or will you clone this
one?

Cheers,
FJP

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 27 Mar 2005 00:09:57 +0100
From: Frans Pop <email address hidden>
To: Marc Haber <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Saturday 26 March 2005 06:47, Marc Haber wrote:
> > The only thing I did notice is that, if I run 'dpkg-reconfigure
> > exim4-config' _after_ the installation is completed, "restarting MTA"
> > takes a very long time (something like 30 seconds), but only the
> > first time I do it.
>
> That sounds like a DNS issue. Exim tries to resolve its own hostname,
> and if that cannot be done, it waits for a DNS timeout. Usual remedy
> is making sure that the local hostname (hostname _and_ FQDN) is
> resolvable via /etc/hosts, since for a new install the hostname is
> unlikely to be available via DNS. See the second FAQ question in
> README.Debian

No, that's not it. Both systems are known on my DNS server. It could still
well be a DNS issue, but nothing that easy.

> > During recent normal installations from Sarge (on different archs),
> > I've seen a similar problem: on the first shutdown after installation
> > it takes a very long time to "stop MTA".
>
> That's a new one. Can you try setting EX4DEBUG to a non-empty value
> and see where the delay is happening?

I've reproduced it just now during an installation using the sparc64 RC3
netinst CD. The pause during power off is at the "start-stop-daemon
--stop" command.
The pause is about the same as when exim is being restarted during
reconfiguration in the first situation.

During previous installations with "local mail only", the default for the
hostname would mostly be the system name. Now I see
"localhost.localdomain" in some (all?) installations. Could that be the
root cause for both these issues?

This could be something from the d-i installation.
On this new Sparc installation I get in /etc/hosts (DHCP with fixed
address):
127.0.0.1 localhost.localdomain localhost gimli

On another installation I have:
127.0.0.1 localhost.localdomain localhost
10.19.66.2 elrond.fjphome.nl elrond

So on the new install the FQN is missing in /etc/hosts, but it is also
readily supplied by my DNS server:
fjp@gimli:~$ ping gimli.fjphome.nl
PING gimli.fjphome.nl (10.19.66.9) 56(84) bytes of data.
64 bytes from gimli.fjphome.nl (10.19.66.9): icmp_seq=1 ttl=64 time=0.273
ms
64 bytes from gimli.fjphome.nl (10.19.66.9): icmp_seq=2 ttl=64 time=0.083
ms

Would you like me to file a separate BR for this or will you clone this
one?

Cheers,
FJP

[Marc Haber (mh+debian-packages)]

On Sun, Mar 27, 2005 at 12:09:57AM +0100, Frans Pop wrote:
> On Saturday 26 March 2005 06:47, Marc Haber wrote:
> > > The only thing I did notice is that, if I run 'dpkg-reconfigure
> > > exim4-config' _after_ the installation is completed, "restarting MTA"
> > > takes a very long time (something like 30 seconds), but only the
> > > first time I do it.
> >
> > That sounds like a DNS issue. Exim tries to resolve its own hostname,
> > and if that cannot be done, it waits for a DNS timeout. Usual remedy
> > is making sure that the local hostname (hostname _and_ FQDN) is
> > resolvable via /etc/hosts, since for a new install the hostname is
> > unlikely to be available via DNS. See the second FAQ question in
> > README.Debian
>
> No, that's not it. Both systems are known on my DNS server. It could still
> well be a DNS issue, but nothing that easy.

An ipv6 issue, maybe? How does your system behave when you search for
an AAAA Record for your hostname? Does /etc/hostname have an FQDN or
only a name? What does exim do when you set "dns_ipv4_lookup = *" in
the main configuration setup? What does exim do when you set
"primary_hostname = your_hostname" in the main configuration setup?

> > > During recent normal installations from Sarge (on different archs),
> > > I've seen a similar problem: on the first shutdown after installation
> > > it takes a very long time to "stop MTA".
> >
> > That's a new one. Can you try setting EX4DEBUG to a non-empty value
> > and see where the delay is happening?
>
> I've reproduced it just now during an installation using the sparc64 RC3
> netinst CD. The pause during power off is at the "start-stop-daemon
> --stop" command.
> The pause is about the same as when exim is being restarted during
> reconfiguration in the first situation.

I see. Is this reproducible in a system state where stracing both
start-stop-daemon and the actual daemon is possible? Does the delay
also happen when you manually determine the PID and sent it a SIGTERM
directly?

> During previous installations with "local mail only", the default for the
> hostname would mostly be the system name. Now I see
> "localhost.localdomain" in some (all?) installations. Could that be the
> root cause for both these issues?
>
> This could be something from the d-i installation.
> On this new Sparc installation I get in /etc/hosts (DHCP with fixed
> address):
> 127.0.0.1 localhost.localdomain localhost gimli
>
> On another installation I have:
> 127.0.0.1 localhost.localdomain localhost
> 10.19.66.2 elrond.fjphome.nl elrond
>
> So on the new install the FQN is missing in /etc/hosts, but it is also
> readily supplied by my DNS server:
> fjp@gimli:~$ ping gimli.fjphome.nl
> PING gimli.fjphome.nl (10.19.66.9) 56(84) bytes of data.
> 64 bytes from gimli.fjphome.nl (10.19.66.9): icmp_seq=1 ttl=64 time=0.273
> ms
> 64 bytes from gimli.fjphome.nl (10.19.66.9): icmp_seq=2 ttl=64 time=0.083
> ms

Is ipv6 part of the game?

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose th...

[Frans Pop (aragorn)]

(also including joeyh as it looks like the cause may be in base-config)

On Sunday 27 March 2005 07:23, you wrote:
> An ipv6 issue, maybe?
Doubt it. See below.

> How does your system behave when you search for an AAAA Record for your
> hostname?
Not tried.

> Does /etc/hostname have an FQDN or only a name?
Only the system name.

> What does exim do when you set "dns_ipv4_lookup = *" in the main
> configuration setup?
> What does exim do when you set "primary_hostname = your_hostname" in the
> main configuration setup?
What main config setup do you mean? /etc/exim4/exim4.conf.template?
Do you mean "primary_hostname = your_hostname" literally or
"primary_hostname = gimli.fjphome.nl"?

> I see. Is this reproducible in a system state where stracing both
> start-stop-daemon and the actual daemon is possible? Does the delay
> also happen when you manually determine the PID and sent it a SIGTERM
> directly?

I've managed to strace the start-stop-daemon. Output attached.

I've also got a better handle on the problem. It definitely has to do with
base-config and can be reproduced as follows:
- 'su' to root
- run 'base-config new'
  - select menu option to configure MTA: no questions are asked, but exim
    is restarted
  - finish base-config
- run '/etc/init.d/exim4 stop

I've seen that 'base-config new' executes
   dpkg-reconfigure --unseen-only --default-priority exim4-config
Executing that from the command prompt and then stopping exim4 does not
reproduce the problem.
So it must be something that happens during initialization or finishing
base-config, or because dpkg-reconfigure is run from within base-config.

Hope this gives you enough clues. Please ask if you need more info.

Cheers,
Frans

[Marc Haber (mh+debian-packages)]

Hi,

On Sun, Mar 27, 2005 at 07:25:07PM +0200, Frans Pop wrote:
> On Sunday 27 March 2005 07:23, you wrote:
> > How does your system behave when you search for an AAAA Record for your
> > hostname?
> Not tried.

Can you please try that?

> > What does exim do when you set "dns_ipv4_lookup = *" in the main
> > configuration setup?
> > What does exim do when you set "primary_hostname = your_hostname" in the
> > main configuration setup?
> What main config setup do you mean? /etc/exim4/exim4.conf.template?

I mean the "main" part of the exim configuration, which is the
beginning of /etc/exim4/exim4.conf.template is you have chosen all
default values during configuration. If you send me your
/etc/exim4/update-exim4.conf.conf, I can see what configuration your
exim uses.

> Do you mean "primary_hostname = your_hostname" literally or
> "primary_hostname = gimli.fjphome.nl"?

primary_hostname = gimli.fjphome.nl

The idea is to tell exim the name of the local host so that it doesn't
need to guess.

> > I see. Is this reproducible in a system state where stracing both
> > start-stop-daemon and the actual daemon is possible? Does the delay
> > also happen when you manually determine the PID and sent it a SIGTERM
> > directly?
>
> I've managed to strace the start-stop-daemon. Output attached.

And where was the 30 seconds delay? strace has an option to put
timestamps into the trace, that would be helpful here.

> I've also got a better handle on the problem. It definitely has to do with
> base-config and can be reproduced as follows:
> - 'su' to root
> - run 'base-config new'
> - select menu option to configure MTA: no questions are asked, but exim
> is restarted
> - finish base-config
> - run '/etc/init.d/exim4 stop

The call to exim4 stop returns after 0m0.011s real time on my system.

> Hope this gives you enough clues. Please ask if you need more info.

An strace of start-stop-daemon and the exim daemon with timestamps
enabled would be nice.

You could als tcpdump or ethereal the network traffic between your
system and the name servers to see which queries your system sends out.

Greetings
Marc, still suspecting a name service problem.

--
-----------------------------------------------------------------------------
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

[Frans Pop (aragorn)]

On Sunday 27 March 2005 19:47, Marc Haber wrote:
> And where was the 30 seconds delay? strace has an option to put
> timestamps into the trace, that would be helpful here.

The delay is during all the repeats of:
<snip>
kill(1235, SIG_0) = 0
gettimeofday({1111935399, ######}, NULL) = 0
select(0, NULL, NULL, NULL, {0, 20000}) = 0 (Timeout)
gettimeofday({1111935399, ######}, NULL) = 0
open("/var/run/exim4/exim.pid", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7001a000
read(3, "1235\n", 8192) = 5
stat64("/proc/1235/exe", {st_mode=S_IFREG|S_ISUID|0755,
st_size=645744, ...}) = 0
close(3) = 0
munmap(0x7001a000, 8192) = 0
</snip>

I'll get back with the rest later.

[Marc Haber (mh+debian-packages)]

On Sun, Mar 27, 2005 at 08:19:05PM +0200, Frans Pop wrote:
> On Sunday 27 March 2005 19:47, Marc Haber wrote:
> > And where was the 30 seconds delay? strace has an option to put
> > timestamps into the trace, that would be helpful here.
>
> The delay is during all the repeats of:
> <snip>
> kill(1235, SIG_0) = 0
> gettimeofday({1111935399, ######}, NULL) = 0
> select(0, NULL, NULL, NULL, {0, 20000}) = 0 (Timeout)
> gettimeofday({1111935399, ######}, NULL) = 0
> open("/var/run/exim4/exim.pid", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7001a000
> read(3, "1235\n", 8192) = 5
> stat64("/proc/1235/exe", {st_mode=S_IFREG|S_ISUID|0755,
> st_size=645744, ...}) = 0
> close(3) = 0
> munmap(0x7001a000, 8192) = 0
> </snip>
>
> I'll get back with the rest later.

Can you see if the pid in /var/run/exim4/exim.pid is really the pid of
the running process? Possibly the pidfile gets desynced with the
daemon and s-s-d tries to kill a non-existing daemon?

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

[Marc Haber (mh+debian-packages)]

On Sun, Mar 27, 2005 at 08:31:21PM +0200, Marc Haber wrote:
> Can you see if the pid in /var/run/exim4/exim.pid is really the pid of
> the running process? Possibly the pidfile gets desynced with the
> daemon and s-s-d tries to kill a non-existing daemon?

Additionally, try putting a different value as --retry parameter in
the init script to find out whether it is s-s-d's timeout we are
dealing with.

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

[Frans Pop (aragorn)]

Additional info on reproducing the problem:
- just running 'base-config new' without configuring exim does not
  reproduce the problem;
- running 'base-config' without 'new' and configuring exim (the config
  questions are asked) does not reproduce the problem;
- after stopping exim with the long pause, subsequent
  starts/restarts/stops are completely normal.

Copy of config attached.

On Sunday 27 March 2005 19:47, Marc Haber wrote:
> > > How does your system behave when you search for an AAAA Record for
> > > your hostname?

gimli:/home/fjp# host -t AAAA gimli.fjphome.nl
(empty, but immediate response)
gimli:/home/fjp# host -t A gimli.fjphome.nl
gimli.fjphome.nl has address 10.19.66.9

> > > What does exim do when you set "dns_ipv4_lookup = *" in the main
> > > configuration setup?
> > > What does exim do when you set "primary_hostname = your_hostname"
> > > in the main configuration setup?

Adding those settings makes no difference at all.

> You could als tcpdump or ethereal the network traffic between your
> system and the name servers to see which queries your system sends out.

There is absolutely no traffic from/to the system during the pause. The
same is true for a normal stop (without the pause).
(So much for the ipv6 theory ;-)

To your other questions.
- The pid matches.
- It is indeed the --retry timeout of s-s-d. After setting that to 10, the
  pause was reduced to exactly 10 seconds (which means my guestimate of
  the original pause was amazingly accurate as well ;-)
  A timed strace of s-s-d with the 10 second retry setting is attached.

I have checked that the exim deamon really is still running during the
retry timeout and that it is gone on completion.

[Frans Pop (aragorn)]

On Sunday 27 March 2005 19:47, Marc Haber wrote:
> An strace of start-stop-daemon and the exim daemon with timestamps
> enabled would be nice.
>
OK. Here's the last piece of the puzzle. The strace for the daemon gives:
Process 7475 attached - interrupt to quit
21:04:29.883761 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
21:04:40.296456 --- SIGTERM (Terminated) @ 0 (0) ---
21:04:40.297103 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
21:04:50.309359 +++ killed by SIGKILL +++

The pause is clearly visible in the timings between the last 2 lines.

[Marc Haber (mh+debian-packages)]

Ok. We are nearing the goal now.

On Sun, Mar 27, 2005 at 11:10:12PM +0200, Frans Pop wrote:
> On Sunday 27 March 2005 19:47, Marc Haber wrote:
> > An strace of start-stop-daemon and the exim daemon with timestamps
> > enabled would be nice.
> >
> OK. Here's the last piece of the puzzle. The strace for the daemon gives:
> Process 7475 attached - interrupt to quit
> 21:04:29.883761 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
> 21:04:40.296456 --- SIGTERM (Terminated) @ 0 (0) ---
> 21:04:40.297103 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
> 21:04:50.309359 +++ killed by SIGKILL +++
>
> The pause is clearly visible in the timings between the last 2 lines.

How does that strace look like in a situation where the daemon
immediately dies?

When I tried to reproduce, I once accidentally started base-config in
an strace, and was unable to kill the base-config process with Ctrl-C
which _usually_ works.

Is it possible that the installer establishes a signal handler which
is then inherited by the processes started from the installer, and
thus the SIGTERM sent by s-s-d to exim is caught by that handler
instead of getting through to exim?

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

[Frans Pop (aragorn)]

[including joeyh again as it looks like base-config really is (contributing
to) the cause]

On Sunday 27 March 2005 23:38, Marc Haber wrote:
> How does that strace look like in a situation where the daemon
> immediately dies?

Process 7725 attached - interrupt to quit
21:52:16.851305 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
21:52:30.435597 --- SIGTERM (Terminated) @ 0 (0) ---
Process 7725 detached

> Is it possible that the installer establishes a signal handler which
> is then inherited by the processes started from the installer, and
> thus the SIGTERM sent by s-s-d to exim is caught by that handler
> instead of getting through to exim?

Could well be. /usr/sbin/base-config has:

<snip>
if [ "$NEW" ]; then
        # Trap most signals because a ctrl-c killing base-config
        # in the middle of the second stage install would be bad.
        trap "" HUP INT QUIT TERM

        [some lines not included]
else
        # Running again on an existing install. Just trap ctrl-c, and
        # cleanly exit.
        trap cleanup INT
fi
</snip>

The only problem is that, looking at the SVN repo for base-config, this code
has been in there for a long time.
So how come this pause has only recently become visible? I'm fairly sure that
the pause was not there a few months ago (although I do 2nd stage installations
a lot less than 1st stage installations). I will try to check this tomorrow.

Cheers,
Frans

[Marc Haber (mh+debian-packages)]

On Mon, Mar 28, 2005 at 12:21:52AM +0200, Frans Pop wrote:
> The only problem is that, looking at the SVN repo for base-config, this code
> has been in there for a long time.
> So how come this pause has only recently become visible? I'm fairly sure that
> the pause was not there a few months ago (although I do 2nd stage installations
> a lot less than 1st stage installations). I will try to check this tomorrow.

You can cross-check with an older version of exim4 from
snapshot.debian.net

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

[Eugeniy Meshcheryakov (eugen)]

28.03.2005 о 00:21 +0200 Frans Pop написав(-ла):
> > Is it possible that the installer establishes a signal handler which
> > is then inherited by the processes started from the installer, and
> > thus the SIGTERM sent by s-s-d to exim is caught by that handler
> > instead of getting through to exim?
>
> Could well be. /usr/sbin/base-config has:
>
> <snip>
> if [ "$NEW" ]; then
> # Trap most signals because a ctrl-c killing base-config
> # in the middle of the second stage install would be bad.
> trap "" HUP INT QUIT TERM
>
> [some lines not included]
> else
> # Running again on an existing install. Just trap ctrl-c, and
> # cleanly exit.
> trap cleanup INT
> fi
> </snip>
>

Here is part of diff of contents of /proc/$PID/status files for exim run
form command line and from base-config:

24c24
< SigIgn: 0000000000001000
---
> SigIgn: 0000000000005006

Those new ignored signals are INT (2+1), QUIT (3+1) and TERM (14+1).

--
Eugeniy Meshcheryakov

Kyiv National Taras Shevchenko University
Information and Computing Centre
http://icc.univ.kiev.ua

[Frans Pop (aragorn)]

On Monday 28 March 2005 00:21, Frans Pop wrote:
> So how come this pause has only recently become visible? I'm fairly
> sure that the pause was not there a few months ago (although I do 2nd
> stage installations a lot less than 1st stage installations).

OK. I've tested with the RC2 netinst CD which had exim4 version 4.34-7.

The difference is that exim used to only reload the config files on a
-reconfigure, while now it does a restart.

So, in the old situation the exim4 deamon started on system boot would
keep running, but now the old daemon is stopped and a new daemon is
started which indeed seems to inherit the SigIgnore settings from
base-config.

I tried adding a line with 'trap "" INT' to the script
/usr/lib/base-config/menu/mta but that did not help; apparently that does
not "untrap" the other signals.

[Marc Haber (mh+debian-packages)]

On Mon, Mar 28, 2005 at 03:52:00PM +0300, Eugeniy Meshcheryakov wrote:
> 28.03.2005 ?? 00:21 +0200 Frans Pop ??????????????(-????):
> > > Is it possible that the installer establishes a signal handler which
> > > is then inherited by the processes started from the installer, and
> > > thus the SIGTERM sent by s-s-d to exim is caught by that handler
> > > instead of getting through to exim?
> >
> > Could well be. /usr/sbin/base-config has:
> >
> > <snip>
> > if [ "$NEW" ]; then
> > # Trap most signals because a ctrl-c killing base-config
> > # in the middle of the second stage install would be bad.
> > trap "" HUP INT QUIT TERM
> >
> > [some lines not included]
> > else
> > # Running again on an existing install. Just trap ctrl-c, and
> > # cleanly exit.
> > trap cleanup INT
> > fi
> > </snip>
> >
>
> Here is part of diff of contents of /proc/$PID/status files for exim run
> form command line and from base-config:
>
> 24c24
> < SigIgn: 0000000000001000
> ---
> > SigIgn: 0000000000005006
>
> Those new ignored signals are INT (2+1), QUIT (3+1) and TERM (14+1).

So exim is configured by base-config to ignore SIGTERM? No wonder that
it wouldn't die.

I'd call that a base-config issue.

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 27 Mar 2005 07:23:12 +0200
From: Marc Haber <email address hidden>
To: Frans Pop <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Sun, Mar 27, 2005 at 12:09:57AM +0100, Frans Pop wrote:
> On Saturday 26 March 2005 06:47, Marc Haber wrote:
> > > The only thing I did notice is that, if I run 'dpkg-reconfigure
> > > exim4-config' _after_ the installation is completed, "restarting MTA"
> > > takes a very long time (something like 30 seconds), but only the
> > > first time I do it.
> >
> > That sounds like a DNS issue. Exim tries to resolve its own hostname,
> > and if that cannot be done, it waits for a DNS timeout. Usual remedy
> > is making sure that the local hostname (hostname _and_ FQDN) is
> > resolvable via /etc/hosts, since for a new install the hostname is
> > unlikely to be available via DNS. See the second FAQ question in
> > README.Debian
>
> No, that's not it. Both systems are known on my DNS server. It could still
> well be a DNS issue, but nothing that easy.

An ipv6 issue, maybe? How does your system behave when you search for
an AAAA Record for your hostname? Does /etc/hostname have an FQDN or
only a name? What does exim do when you set "dns_ipv4_lookup = *" in
the main configuration setup? What does exim do when you set
"primary_hostname = your_hostname" in the main configuration setup?

> > > During recent normal installations from Sarge (on different archs),
> > > I've seen a similar problem: on the first shutdown after installation
> > > it takes a very long time to "stop MTA".
> >
> > That's a new one. Can you try setting EX4DEBUG to a non-empty value
> > and see where the delay is happening?
>
> I've reproduced it just now during an installation using the sparc64 RC3
> netinst CD. The pause during power off is at the "start-stop-daemon
> --stop" command.
> The pause is about the same as when exim is being restarted during
> reconfiguration in the first situation.

I see. Is this reproducible in a system state where stracing both
start-stop-daemon and the actual daemon is possible? Does the delay
also happen when you manually determine the PID and sent it a SIGTERM
directly?

> During previous installations with "local mail only", the default for the
> hostname would mostly be the system name. Now I see
> "localhost.localdomain" in some (all?) installations. Could that be the
> root cause for both these issues?
>
> This could be something from the d-i installation.
> On this new Sparc installation I get in /etc/hosts (DHCP with fixed
> address):
> 127.0.0.1 localhost.localdomain localhost gimli
>
> On another installation I have:
> 127.0.0.1 localhost.localdomain localhost
> 10.19.66.2 elrond.fjphome.nl elrond
>
> So on the new install the FQN is missing in /etc/hosts, but it is also
> readily supplied by my DNS server:
> fjp@gimli:~$ ping gimli.fjphome.nl
> PING gimli.fjphome.nl (10.19.66.9) 56(84) bytes of data.
> 64 bytes from gimli.fjphome.nl (10.19.6...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 27 Mar 2005 19:25:07 +0200
From: Frans Pop <email address hidden>
To: Marc Haber <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

--Boundary-00=_0xuRC6sHsxf4IYV
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

(also including joeyh as it looks like the cause may be in base-config)

On Sunday 27 March 2005 07:23, you wrote:
> An ipv6 issue, maybe?
Doubt it. See below.

> How does your system behave when you search for an AAAA Record for your
> hostname?
Not tried.

> Does /etc/hostname have an FQDN or only a name?
Only the system name.

> What does exim do when you set "dns_ipv4_lookup = *" in the main
> configuration setup?
> What does exim do when you set "primary_hostname = your_hostname" in the
> main configuration setup?
What main config setup do you mean? /etc/exim4/exim4.conf.template?
Do you mean "primary_hostname = your_hostname" literally or
"primary_hostname = gimli.fjphome.nl"?

> I see. Is this reproducible in a system state where stracing both
> start-stop-daemon and the actual daemon is possible? Does the delay
> also happen when you manually determine the PID and sent it a SIGTERM
> directly?

I've managed to strace the start-stop-daemon. Output attached.

I've also got a better handle on the problem. It definitely has to do with
base-config and can be reproduced as follows:
- 'su' to root
- run 'base-config new'
  - select menu option to configure MTA: no questions are asked, but exim
    is restarted
  - finish base-config
- run '/etc/init.d/exim4 stop

I've seen that 'base-config new' executes
   dpkg-reconfigure --unseen-only --default-priority exim4-config
Executing that from the command prompt and then stopping exim4 does not
reproduce the problem.
So it must be something that happens during initialization or finishing
base-config, or because dpkg-reconfigure is run from within base-config.

Hope this gives you enough clues. Please ask if you need more info.

Cheers,
Frans

--Boundary-00=_0xuRC6sHsxf4IYV
Content-Type: application/x-gzip;
  name="exim4err.log.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="exim4err.log.gz"

H4sICHrnRkIAA2V4aW00ZXJyLmxvZwDtnV+PXcWVxd/5FFd+sqMGn/pf9YBGaGgiK8ZGxswkGiKr
aTfQwnaj7nbGDOS7T+1zDoMbMK51kiNNWIuI4DjdXZd7f961zq5da529Ojv929ntW3evvjh/cffq
+uTy+t2r64tv3316cvb84sWto8N/3fq137317vwby6++PX/65fmzM/sfd/92cnn38uWLu2evzp/H
+b/f6//38nUX37y4eHqx/Pry7PryO/tlmJbfOOuvZP4JL68ul1cz/4hbf+0v4e4fDs4f+o++Ovzh
7l/vHN4/TO+8fHHy/Oz291ffXb1/6/75i5ev+jf3H3/2/q2vzp8/O+//67333vv78rVfXH5ze7pz
eOtf/Wtf+XiSpndOTk/Prq76+3J2fXr32dP3ri7ee3Hx9X+fnti/8kdPHv7pzo/f8a47HD94ePzg
8eH2g4vD1cvTrw/2ZhwuLg9Pzy/PTq8vLr+7887Ft2cvbvy0by/Pnl2c2Bvz8MmjDx8+uP+XO//Q
zzs9Of367Oc/zX5eeOfL/gFe53g7HB2+v7p+8tzepE+f3Pvo0fEff5hyjEeH/rtX5/9z9r5LLtTX
37jnz0++vf3gs/v3jw7r//fJo4ePnzw6/uDDo8PHH3zy5JNH9/7jg8fHR4f+w6f5e16VaXKn0zS9
c/rs4ursdnjr+24L7fR+Pzv/wv4+tZ+Xf/nuLO/P5dnJU3tzbn3uSjm+/9Hn7nPf/55+5T+h/+3X
X7v57+Dyrf5+HR2S8/bv...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 27 Mar 2005 19:47:36 +0200
From: Marc Haber <email address hidden>
To: Frans Pop <email address hidden>
Cc: Marc Haber <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

Hi,

On Sun, Mar 27, 2005 at 07:25:07PM +0200, Frans Pop wrote:
> On Sunday 27 March 2005 07:23, you wrote:
> > How does your system behave when you search for an AAAA Record for your
> > hostname?
> Not tried.

Can you please try that?

> > What does exim do when you set "dns_ipv4_lookup = *" in the main
> > configuration setup?
> > What does exim do when you set "primary_hostname = your_hostname" in the
> > main configuration setup?
> What main config setup do you mean? /etc/exim4/exim4.conf.template?

I mean the "main" part of the exim configuration, which is the
beginning of /etc/exim4/exim4.conf.template is you have chosen all
default values during configuration. If you send me your
/etc/exim4/update-exim4.conf.conf, I can see what configuration your
exim uses.

> Do you mean "primary_hostname = your_hostname" literally or
> "primary_hostname = gimli.fjphome.nl"?

primary_hostname = gimli.fjphome.nl

The idea is to tell exim the name of the local host so that it doesn't
need to guess.

> > I see. Is this reproducible in a system state where stracing both
> > start-stop-daemon and the actual daemon is possible? Does the delay
> > also happen when you manually determine the PID and sent it a SIGTERM
> > directly?
>
> I've managed to strace the start-stop-daemon. Output attached.

And where was the 30 seconds delay? strace has an option to put
timestamps into the trace, that would be helpful here.

> I've also got a better handle on the problem. It definitely has to do with
> base-config and can be reproduced as follows:
> - 'su' to root
> - run 'base-config new'
> - select menu option to configure MTA: no questions are asked, but exim
> is restarted
> - finish base-config
> - run '/etc/init.d/exim4 stop

The call to exim4 stop returns after 0m0.011s real time on my system.

> Hope this gives you enough clues. Please ask if you need more info.

An strace of start-stop-daemon and the exim daemon with timestamps
enabled would be nice.

You could als tcpdump or ethereal the network traffic between your
system and the name servers to see which queries your system sends out.

Greetings
Marc, still suspecting a name service problem.

--
-----------------------------------------------------------------------------
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

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 27 Mar 2005 20:19:05 +0200
From: Frans Pop <email address hidden>
To: Marc Haber <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Sunday 27 March 2005 19:47, Marc Haber wrote:
> And where was the 30 seconds delay? strace has an option to put
> timestamps into the trace, that would be helpful here.

The delay is during all the repeats of:
<snip>
kill(1235, SIG_0) = 0
gettimeofday({1111935399, ######}, NULL) = 0
select(0, NULL, NULL, NULL, {0, 20000}) = 0 (Timeout)
gettimeofday({1111935399, ######}, NULL) = 0
open("/var/run/exim4/exim.pid", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7001a000
read(3, "1235\n", 8192) = 5
stat64("/proc/1235/exe", {st_mode=S_IFREG|S_ISUID|0755,
st_size=645744, ...}) = 0
close(3) = 0
munmap(0x7001a000, 8192) = 0
</snip>

I'll get back with the rest later.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 27 Mar 2005 20:31:21 +0200
From: Marc Haber <email address hidden>
To: Frans Pop <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Sun, Mar 27, 2005 at 08:19:05PM +0200, Frans Pop wrote:
> On Sunday 27 March 2005 19:47, Marc Haber wrote:
> > And where was the 30 seconds delay? strace has an option to put
> > timestamps into the trace, that would be helpful here.
>
> The delay is during all the repeats of:
> <snip>
> kill(1235, SIG_0) = 0
> gettimeofday({1111935399, ######}, NULL) = 0
> select(0, NULL, NULL, NULL, {0, 20000}) = 0 (Timeout)
> gettimeofday({1111935399, ######}, NULL) = 0
> open("/var/run/exim4/exim.pid", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7001a000
> read(3, "1235\n", 8192) = 5
> stat64("/proc/1235/exe", {st_mode=S_IFREG|S_ISUID|0755,
> st_size=645744, ...}) = 0
> close(3) = 0
> munmap(0x7001a000, 8192) = 0
> </snip>
>
> I'll get back with the rest later.

Can you see if the pid in /var/run/exim4/exim.pid is really the pid of
the running process? Possibly the pidfile gets desynced with the
daemon and s-s-d tries to kill a non-existing daemon?

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 27 Mar 2005 20:32:48 +0200
From: Marc Haber <email address hidden>
To: Frans Pop <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Sun, Mar 27, 2005 at 08:31:21PM +0200, Marc Haber wrote:
> Can you see if the pid in /var/run/exim4/exim.pid is really the pid of
> the running process? Possibly the pidfile gets desynced with the
> daemon and s-s-d tries to kill a non-existing daemon?

Additionally, try putting a different value as --retry parameter in
the init script to find out whether it is s-s-d's timeout we are
dealing with.

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

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 27 Mar 2005 22:09:44 +0200
From: Frans Pop <email address hidden>
To: Marc Haber <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

--Boundary-00=_JMxRCOoVRfjxdF+
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Additional info on reproducing the problem:
- just running 'base-config new' without configuring exim does not
  reproduce the problem;
- running 'base-config' without 'new' and configuring exim (the config
  questions are asked) does not reproduce the problem;
- after stopping exim with the long pause, subsequent
  starts/restarts/stops are completely normal.

Copy of config attached.

On Sunday 27 March 2005 19:47, Marc Haber wrote:
> > > How does your system behave when you search for an AAAA Record for
> > > your hostname?

gimli:/home/fjp# host -t AAAA gimli.fjphome.nl
(empty, but immediate response)
gimli:/home/fjp# host -t A gimli.fjphome.nl
gimli.fjphome.nl has address 10.19.66.9

> > > What does exim do when you set "dns_ipv4_lookup = *" in the main
> > > configuration setup?
> > > What does exim do when you set "primary_hostname = your_hostname"
> > > in the main configuration setup?

Adding those settings makes no difference at all.

> You could als tcpdump or ethereal the network traffic between your
> system and the name servers to see which queries your system sends out.

There is absolutely no traffic from/to the system during the pause. The
same is true for a normal stop (without the pause).
(So much for the ipv6 theory ;-)

To your other questions.
- The pid matches.
- It is indeed the --retry timeout of s-s-d. After setting that to 10, the
  pause was reduced to exactly 10 seconds (which means my guestimate of
  the original pause was amazingly accurate as well ;-)
  A timed strace of s-s-d with the 10 second retry setting is attached.

I have checked that the exim deamon really is still running during the
retry timeout and that it is gone on completion.

--Boundary-00=_JMxRCOoVRfjxdF+
Content-Type: text/plain;
  charset="iso-8859-1";
  name="update-exim4.conf.conf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="update-exim4.conf.conf"

# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'

dc_eximconfig_configtype='local'
dc_other_hostnames='localhost.localdomain'
dc_local_interfaces='127.0.0.1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'

--Boundary-00=_JMxRCOoVRfjxdF+
Content-Type: application/x-gzip;
  name="exim4err.log.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="exim4err.log.gz"

H4sICJoJR0IAA2V4aW00ZXJyLmxvZwC9fW3PnNWR5vf5FY/4ZEbQnPeXkaIV2pgIDYGIkN0ZbUbI
MQ+JFcDINrOwYf771lUNCbbvqr48fU4nIjj0dapuuq8+Xe8V57+k+i8lntrMec67++/vH//n/YO3
3nv+pyff...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 27 Mar 2005 23:10:12 +0200
From: Frans Pop <email address hidden>
To: <email address hidden>
Cc: Marc Haber <email address hidden>,
 <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Sunday 27 March 2005 19:47, Marc Haber wrote:
> An strace of start-stop-daemon and the exim daemon with timestamps
> enabled would be nice.
>
OK. Here's the last piece of the puzzle. The strace for the daemon gives:
Process 7475 attached - interrupt to quit
21:04:29.883761 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
21:04:40.296456 --- SIGTERM (Terminated) @ 0 (0) ---
21:04:40.297103 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
21:04:50.309359 +++ killed by SIGKILL +++

The pause is clearly visible in the timings between the last 2 lines.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 27 Mar 2005 23:38:47 +0200
From: Marc Haber <email address hidden>
To: Frans Pop <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

Ok. We are nearing the goal now.

On Sun, Mar 27, 2005 at 11:10:12PM +0200, Frans Pop wrote:
> On Sunday 27 March 2005 19:47, Marc Haber wrote:
> > An strace of start-stop-daemon and the exim daemon with timestamps
> > enabled would be nice.
> >
> OK. Here's the last piece of the puzzle. The strace for the daemon gives:
> Process 7475 attached - interrupt to quit
> 21:04:29.883761 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
> 21:04:40.296456 --- SIGTERM (Terminated) @ 0 (0) ---
> 21:04:40.297103 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
> 21:04:50.309359 +++ killed by SIGKILL +++
>
> The pause is clearly visible in the timings between the last 2 lines.

How does that strace look like in a situation where the daemon
immediately dies?

When I tried to reproduce, I once accidentally started base-config in
an strace, and was unable to kill the base-config process with Ctrl-C
which _usually_ works.

Is it possible that the installer establishes a signal handler which
is then inherited by the processes started from the installer, and
thus the SIGTERM sent by s-s-d to exim is caught by that handler
instead of getting through to exim?

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

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 28 Mar 2005 00:21:52 +0200
From: Frans Pop <email address hidden>
To: Marc Haber <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

[including joeyh again as it looks like base-config really is (contributing
to) the cause]

On Sunday 27 March 2005 23:38, Marc Haber wrote:
> How does that strace look like in a situation where the daemon
> immediately dies?

Process 7725 attached - interrupt to quit
21:52:16.851305 select(1, [0], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
21:52:30.435597 --- SIGTERM (Terminated) @ 0 (0) ---
Process 7725 detached

> Is it possible that the installer establishes a signal handler which
> is then inherited by the processes started from the installer, and
> thus the SIGTERM sent by s-s-d to exim is caught by that handler
> instead of getting through to exim?

Could well be. /usr/sbin/base-config has:

<snip>
if [ "$NEW" ]; then
        # Trap most signals because a ctrl-c killing base-config
        # in the middle of the second stage install would be bad.
        trap "" HUP INT QUIT TERM

        [some lines not included]
else
        # Running again on an existing install. Just trap ctrl-c, and
        # cleanly exit.
        trap cleanup INT
fi
</snip>

The only problem is that, looking at the SVN repo for base-config, this code
has been in there for a long time.
So how come this pause has only recently become visible? I'm fairly sure that
the pause was not there a few months ago (although I do 2nd stage installations
a lot less than 1st stage installations). I will try to check this tomorrow.

Cheers,
Frans

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 28 Mar 2005 07:15:47 +0200
From: Marc Haber <email address hidden>
To: Frans Pop <email address hidden>
Cc: <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Mon, Mar 28, 2005 at 12:21:52AM +0200, Frans Pop wrote:
> The only problem is that, looking at the SVN repo for base-config, this code
> has been in there for a long time.
> So how come this pause has only recently become visible? I'm fairly sure that
> the pause was not there a few months ago (although I do 2nd stage installations
> a lot less than 1st stage installations). I will try to check this tomorrow.

You can cross-check with an older version of exim4 from
snapshot.debian.net

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 28 Mar 2005 15:52:00 +0300
From: Eugeniy Meshcheryakov <email address hidden>
To: Marc Haber <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

28.03.2005 =D0=BE 00:21 +0200 Frans Pop =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0=D0=B2(-=D0=BB=D0=B0):
> > Is it possible that the installer establishes a signal handler which
> > is then inherited by the processes started from the installer, and
> > thus the SIGTERM sent by s-s-d to exim is caught by that handler
> > instead of getting through to exim?
>=20
> Could well be. /usr/sbin/base-config has:
>=20
> <snip>
> if [ "$NEW" ]; then
> # Trap most signals because a ctrl-c killing base-config
> # in the middle of the second stage install would be bad.
> trap "" HUP INT QUIT TERM
>=20
> [some lines not included]
> else
> # Running again on an existing install. Just trap ctrl-c, and
> # cleanly exit.
> trap cleanup INT
> fi
> </snip>
>=20

Here is part of diff of contents of /proc/$PID/status files for exim run
form command line and from base-config:

24c24
< SigIgn: 0000000000001000
---
> SigIgn: 0000000000005006

Those new ignored signals are INT (2+1), QUIT (3+1) and TERM (14+1).

--=20
Eugeniy Meshcheryakov

Kyiv National Taras Shevchenko University
Information and Computing Centre
http://icc.univ.kiev.ua

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCR/3wKaC6+zmozOIRAuFmAJ4gVZsKlJcPSGlUhCDdTn74kB10XwCggg5S
PFX062LacYqE9vSTMDXArvU=
=iVZs
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--

[Eugeniy Meshcheryakov (eugen)]

28.03.2005 о 16:28 +0200 Frans Pop написав(-ла):
> On Monday 28 March 2005 00:21, Frans Pop wrote:
> > So how come this pause has only recently become visible? I'm fairly
> > sure that the pause was not there a few months ago (although I do 2nd
> > stage installations a lot less than 1st stage installations).
>
> OK. I've tested with the RC2 netinst CD which had exim4 version 4.34-7.
>
> The difference is that exim used to only reload the config files on a
> -reconfigure, while now it does a restart.
>
> So, in the old situation the exim4 deamon started on system boot would
> keep running, but now the old daemon is stopped and a new daemon is
> started which indeed seems to inherit the SigIgnore settings from
> base-config.
>
> I tried adding a line with 'trap "" INT' to the script
> /usr/lib/base-config/menu/mta but that did not help; apparently that does
> not "untrap" the other signals.
>
Try this:

   trap - TERM

--
Eugeniy Meshcheryakov

Kyiv National Taras Shevchenko University
Information and Computing Centre
http://icc.univ.kiev.ua

[Eugeniy Meshcheryakov (eugen)]

28.03.2005 о 18:17 +0300 Eugeniy Meshcheryakov написав:
> > I tried adding a line with 'trap "" INT' to the script
> > /usr/lib/base-config/menu/mta but that did not help; apparently that does
> > not "untrap" the other signals.
> >
> Try this:
>
> trap - TERM
>
And this does not work. Shell that runs /usr/lib/base-config/menu/mta knows
nothing about ignored signals. So the only way to fix this bug is
unignoring signal(s) in base-config itself, not in such scripts like
that.

--
Eugeniy Meshcheryakov

Kyiv National Taras Shevchenko University
Information and Computing Centre
http://icc.univ.kiev.ua

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 28 Mar 2005 16:28:06 +0200
From: Frans Pop <email address hidden>
To: Marc Haber <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Monday 28 March 2005 00:21, Frans Pop wrote:
> So how come this pause has only recently become visible? I'm fairly
> sure that the pause was not there a few months ago (although I do 2nd
> stage installations a lot less than 1st stage installations).

OK. I've tested with the RC2 netinst CD which had exim4 version 4.34-7.

The difference is that exim used to only reload the config files on a
-reconfigure, while now it does a restart.

So, in the old situation the exim4 deamon started on system boot would
keep running, but now the old daemon is stopped and a new daemon is
started which indeed seems to inherit the SigIgnore settings from
base-config.

I tried adding a line with 'trap "" INT' to the script
/usr/lib/base-config/menu/mta but that did not help; apparently that does
not "untrap" the other signals.

[Frans Pop (aragorn)]

On Monday 28 March 2005 17:17, Eugeniy Meshcheryakov wrote:
> Try this:
> trap - TERM

That doesn't work either. From 'info bash':
"Signals ignored upon entry to the shell cannot be trapped or reset."

I also tried 'trap INT', but that fails for the same reason.

[Joey Hess (joeyh)]

Eugeniy Meshcheryakov wrote:
> And this does not work. Shell that runs /usr/lib/base-config/menu/mta knows
> nothing about ignored signals. So the only way to fix this bug is
> unignoring signal(s) in base-config itself, not in such scripts like
> that.

Doing so would be equivilant to removing the signal trapping from
base-config altogether.

There outght to be a better way.

--
see shy jo

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 28 Mar 2005 16:32:57 +0200
From: Marc Haber <email address hidden>
To: Eugeniy Meshcheryakov <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Mon, Mar 28, 2005 at 03:52:00PM +0300, Eugeniy Meshcheryakov wrote:
> 28.03.2005 ?? 00:21 +0200 Frans Pop ??????????????(-????):
> > > Is it possible that the installer establishes a signal handler which
> > > is then inherited by the processes started from the installer, and
> > > thus the SIGTERM sent by s-s-d to exim is caught by that handler
> > > instead of getting through to exim?
> >
> > Could well be. /usr/sbin/base-config has:
> >
> > <snip>
> > if [ "$NEW" ]; then
> > # Trap most signals because a ctrl-c killing base-config
> > # in the middle of the second stage install would be bad.
> > trap "" HUP INT QUIT TERM
> >
> > [some lines not included]
> > else
> > # Running again on an existing install. Just trap ctrl-c, and
> > # cleanly exit.
> > trap cleanup INT
> > fi
> > </snip>
> >
>
> Here is part of diff of contents of /proc/$PID/status files for exim run
> form command line and from base-config:
>
> 24c24
> < SigIgn: 0000000000001000
> ---
> > SigIgn: 0000000000005006
>
> Those new ignored signals are INT (2+1), QUIT (3+1) and TERM (14+1).

So exim is configured by base-config to ignore SIGTERM? No wonder that
it wouldn't die.

I'd call that a base-config issue.

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 28 Mar 2005 18:17:02 +0300
From: Eugeniy Meshcheryakov <email address hidden>
To: Frans Pop <email address hidden>
Cc: Marc Haber <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

28.03.2005 =D0=BE 16:28 +0200 Frans Pop =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0=D0=B2(-=D0=BB=D0=B0):
> On Monday 28 March 2005 00:21, Frans Pop wrote:
> > So how come this pause has only recently become visible? I'm fairly
> > sure that the pause was not there a few months ago (although I do 2nd
> > stage installations a lot less than 1st stage installations).
>=20
> OK. I've tested with the RC2 netinst CD which had exim4 version 4.34-7.
>=20
> The difference is that exim used to only reload the config files on a=20
> -reconfigure, while now it does a restart.
>=20
> So, in the old situation the exim4 deamon started on system boot would=20
> keep running, but now the old daemon is stopped and a new daemon is=20
> started which indeed seems to inherit the SigIgnore settings from=20
> base-config.
>=20
> I tried adding a line with 'trap "" INT' to the script
> /usr/lib/base-config/menu/mta but that did not help; apparently that does=
=20
> not "untrap" the other signals.
>=20
Try this:

   trap - TERM

--=20
Eugeniy Meshcheryakov

Kyiv National Taras Shevchenko University
Information and Computing Centre
http://icc.univ.kiev.ua

--ikeVEW9yuYc//A+q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCSB/uKaC6+zmozOIRAp1NAKCI4UVSUilQO/sxiOkk8hFOQQVbFwCfRa0F
OZHRLL0kXYY6pjCibIWKKXA=
=m2HN
-----END PGP SIGNATURE-----

--ikeVEW9yuYc//A+q--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 28 Mar 2005 18:44:27 +0300
From: Eugeniy Meshcheryakov <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

--3lcZGd9BuhuYXNfi
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

28.03.2005 =D0=BE 18:17 +0300 Eugeniy Meshcheryakov =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0=D0=B2:
> > I tried adding a line with 'trap "" INT' to the script
> > /usr/lib/base-config/menu/mta but that did not help; apparently that do=
es=20
> > not "untrap" the other signals.
> >=20
> Try this:
>=20
> trap - TERM
>=20
And this does not work. Shell that runs /usr/lib/base-config/menu/mta knows
nothing about ignored signals. So the only way to fix this bug is
unignoring signal(s) in base-config itself, not in such scripts like
that.

--=20
Eugeniy Meshcheryakov

Kyiv National Taras Shevchenko University
Information and Computing Centre
http://icc.univ.kiev.ua

--3lcZGd9BuhuYXNfi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD4DBQFCSCZaKaC6+zmozOIRAuREAJjkxuo1GtMamDQ4J+Axdg1W+LlnAJ9iMpTg
DOUZkY9gVgA7XWu/n1ZKOw==
=r0fc
-----END PGP SIGNATURE-----

--3lcZGd9BuhuYXNfi--

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 28 Mar 2005 18:12:40 +0200
From: Frans Pop <email address hidden>
To: <email address hidden>
Cc: Marc Haber <email address hidden>,
 <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

On Monday 28 March 2005 17:17, Eugeniy Meshcheryakov wrote:
> Try this:
> trap - TERM

That doesn't work either. From 'info bash':
"Signals ignored upon entry to the shell cannot be trapped or reset."

I also tried 'trap INT', but that fails for the same reason.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 28 Mar 2005 11:18:05 -0500
From: Joey Hess <email address hidden>
To: Eugeniy Meshcheryakov <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Eugeniy Meshcheryakov wrote:
> And this does not work. Shell that runs /usr/lib/base-config/menu/mta kno=
ws
> nothing about ignored signals. So the only way to fix this bug is
> unignoring signal(s) in base-config itself, not in such scripts like
> that.

Doing so would be equivilant to removing the signal trapping from
base-config altogether.

There outght to be a better way.

--=20
see shy jo

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCSC49d8HHehbQuO8RAm8BAJ9YpMXpuJE66XdWaq20YgrlIcg/4ACfYg+X
QyHX6eqyYtIv2ALvGmropmo=
=qqC3
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--

[Frans Pop (aragorn)]

clone 297607 -1
reassign -1 base-config
retitle -1 base-config's SigIgnore settings cause long pause when stopping exim4 daemon
severity -1 important
thanks

This issue was explored following a test of a new version of exim4 that addressed
the original issue in this bug report.

The new issue is that when the exim4 daemon is stopped the first time after the
installation is completed, there is a long pause because the process has inherited
the 'trap "" TERM' setting for base-config. The pause is equal to the --retry
timeout for start-stop-daemon.

Details in the history of this report (starting from the first message sent by:
Frans Pop <email address hidden>).

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 29 Mar 2005 16:13:30 +0200
From: Frans Pop <email address hidden>
To: <email address hidden>
Cc: Marc Haber <email address hidden>
Subject: Cloning #297607 to base-config: long pause when exim4 daemon is stopped

clone 297607 -1
reassign -1 base-config
retitle -1 base-config's SigIgnore settings cause long pause when stopping exim4 daemon
severity -1 important
thanks

This issue was explored following a test of a new version of exim4 that addressed
the original issue in this bug report.

The new issue is that when the exim4 daemon is stopped the first time after the
installation is completed, there is a long pause because the process has inherited
the 'trap "" TERM' setting for base-config. The pause is equal to the --retry
timeout for start-stop-daemon.

Details in the history of this report (starting from the first message sent by:
Frans Pop <email address hidden>).

[Frans Pop (aragorn)]

On Tuesday 29 March 2005 16:36, you wrote:
> Waiting for your confirmation that 4.50-4 does work with the current
> d-i.

I thought we already established that at the very beginning of the
thread :-)

To make doubly sure, I've downloaded the latest daily build (that already
has 4.50-4) and tested that. No problems.

Cheers,
Frans

[Marc Haber (mh+debian-packages)]

Hi,

On Tue, Mar 29, 2005 at 06:35:16PM +0200, Frans Pop wrote:
> On Tuesday 29 March 2005 16:36, you wrote:
> > Waiting for your confirmation that 4.50-4 does work with the current
> > d-i.
>
> I thought we already established that at the very beginning of the
> thread :-)

Just making sure. Better ask once more than breaking the installer
_again_. I just ran out of brown paper bags.

> To make doubly sure, I've downloaded the latest daily build (that already
> has 4.50-4) and tested that. No problems.

Thanks. Closing this bug.

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

[Joey Hess (joeyh)]

FWIW, I don't see any reason right now why this bug wouldn't affect
other software installed by aptitude as part of the base-config process.
Unless apt un-ignores the signals. If other daemons are affected, this
bug could escalate from an annoying but livable delay stopping exim to
other broken behavior, which could be, arguably, release critical.

--
see shy jo

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 29 Mar 2005 18:35:16 +0200
From: Frans Pop <email address hidden>
To: Marc Haber <email address hidden>
Cc: <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

--nextPart2019062.ap9SnUDlJ2
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 29 March 2005 16:36, you wrote:
> Waiting for your confirmation that 4.50-4 does work with the current
> d-i.

I thought we already established that at the very beginning of the=20
thread :-)

To make doubly sure, I've downloaded the latest daily build (that already=20
has 4.50-4) and tested that. No problems.

Cheers,
=46rans

--nextPart2019062.ap9SnUDlJ2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCSYPNgm/Kwh6ICoQRAkzJAKCtTWSHQ5QweTekHHhFKN9QGR2zqwCfXyuD
JpUCUAh6sb6ZkY+3FJfOWFI=
=XTgt
-----END PGP SIGNATURE-----

--nextPart2019062.ap9SnUDlJ2--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 29 Mar 2005 18:52:33 +0200
From: Marc Haber <email address hidden>
To: Frans Pop <email address hidden>
Cc: <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

Hi,

On Tue, Mar 29, 2005 at 06:35:16PM +0200, Frans Pop wrote:
> On Tuesday 29 March 2005 16:36, you wrote:
> > Waiting for your confirmation that 4.50-4 does work with the current
> > d-i.
>
> I thought we already established that at the very beginning of the
> thread :-)

Just making sure. Better ask once more than breaking the installer
_again_. I just ran out of brown paper bags.

> To make doubly sure, I've downloaded the latest daily build (that already
> has 4.50-4) and tested that. No problems.

Thanks. Closing this bug.

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 29 Mar 2005 12:24:18 -0500
From: Joey Hess <email address hidden>
To: <email address hidden>
Subject: Re: Long pause when exim daemon is being stopped (was: Re: exim4 prone to break d-i,
 bug #297607)

--8P1HSweYDcXXzwPJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

FWIW, I don't see any reason right now why this bug wouldn't affect
other software installed by aptitude as part of the base-config process.
Unless apt un-ignores the signals. If other daemons are affected, this
bug could escalate from an annoying but livable delay stopping exim to
other broken behavior, which could be, arguably, release critical.

--=20
see shy jo

--8P1HSweYDcXXzwPJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD4DBQFCSY9Cd8HHehbQuO8RAk6UAJdS1PrYngkzZ3uknZ70L2dW1md3AKCYKIbO
wZD7avXpOrtRHZEHCWmtkw==
=+I4H
-----END PGP SIGNATURE-----

--8P1HSweYDcXXzwPJ--