Mailing List Archive

On Mon, Nov 08, 2021 at 10:20:44AM -0300, JHM via Exim-users wrote:
> The problem is that my DNS (unbound) runs on the Devuan ascii virtual machine which I set
> up to start up automatically at boot but it is not yet up and running when Exim4 does the
> reverse DNS check.

You can change service dependencies to start DNS before MTA.
The Required-Start: field in Debian SysV-init scripts serves this purpose,
I belive Devuan uses the same init mechanics.
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi

JHM via Exim-users <exim-users@exim.org> (Mo 08 Nov 2021 14:20:44 CET):
> My box runs Devuan Beowulf and within it runs a (VBox) Devuan ascii virtual machine set up
> to start up automatically when I boot.
>
> It is not kept on 24/07 but is booted up a few times every 24 hours.
>
> The Devuan ascii virtual machine runs PI-Hole as a recursive DNS server.
> It is all working as it should but there's a 'snag in the weave' so to speak:
>
> When booting, I'm getting a (not too) short delay at "Starting MTA:" which is when (as I
> understand it) Exim4 does a reverse DNS check.

IMHO Exim doesn't do (reverse) DNS-checks per se. So it depends on your
configuration, whether Exim tries to resolve anything at startup
already.

> The problem is that my DNS (unbound) runs on the Devuan ascii virtual machine which I set
> up to start up automatically at boot but it is not yet up and running when Exim4 does the
> reverse DNS check.

Maybe you can ask your „exim box“ using another resolver and then try to
capture the DNS traffic, to get an idea about the queries that are sent.

Or, simpler, switch on logging on your resolver and check the queries it
receives, if it is Exim, it should either be visible in the resolver
logs, or Exim will write a short notice to its panic- or mainlog.

--
Heiko

On Mon, 8 Nov 2021, JHM via Exim-users wrote:

> Hello:
>
> My box runs Devuan Beowulf and within it runs a (VBox) Devuan ascii
> virtual machine set up to start up automatically when I boot.
>
> It is not kept on 24/07 but is booted up a few times every 24 hours.
>
> The Devuan ascii virtual machine runs PI-Hole as a recursive DNS server.
> It is all working as it should but there's a 'snag in the weave' so to speak:
>
> When booting, I'm getting a (not too) short delay at "Starting MTA:"
> which is when (as I understand it) Exim4 does a reverse DNS check.
>
> The problem is that my DNS (unbound) runs on the Devuan ascii
> virtual machine which I set up to start up automatically at boot but
> it is not yet up and running when Exim4 does the reverse DNS check.
>
> Hence the delay (30/40s?) I am refering to.
>
> Exim4 is set up to receive "local delivery only; not on a network",
> listens only to IP 127.0.0.1 for incoming SMTP connections and
> accepts my box's user as the only other destination for which mail
> is accepted.
>
> As I am on a wired ADSL connection and have "always on" web access,
> "Dial-on-Demand" configuration is disabled.
>
> Is there a way I can avoid the "Starting MTA:" delay at boot?

Well, this is the sort of problem systemd is supposed to avoid :-)

As Evgeniy said, you can do things with the init files to work around
the problem.

Alternatively you could arrange that exim is started by inetd
(perhaps rlinetd or xinetd these days) each time there is a connection,
rather that running as a daemon.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

I believe this is not an Exim-problem, but you can:

1) Take down the DNS and the exim machine, start sniffing on the host,
power up the exim machine:

# tcpdump -i eth? port 53
# start exim-machine

to see what it is querying, add those entries to /etc/hosts in the
exim-machine

and "supposedly" no more delays are going to occur.

--
Fabio Martins
http://nabundapode.com.br/

On 2021-11-08 10:20, JHM via Exim-users wrote:
> Hello:
>
> My box runs Devuan Beowulf and within it runs a (VBox) Devuan ascii
> virtual machine set up
> to start up automatically when I boot.
>
> It is not kept on 24/07 but is booted up a few times every 24 hours.
>
> The Devuan ascii virtual machine runs PI-Hole as a recursive DNS
> server.
> It is all working as it should but there's a 'snag in the weave' so to
> speak:
>
> When booting, I'm getting a (not too) short delay at "Starting MTA:"
> which is when (as I
> understand it) Exim4 does a reverse DNS check.
>
> The problem is that my DNS (unbound) runs on the Devuan ascii virtual
> machine which I set
> up to start up automatically at boot but it is not yet up and running
> when Exim4 does the
> reverse DNS check.
>
> Hence the delay (30/40s?) I am refering to.
>
> Exim4 is set up to receive "local delivery only; not on a network",
> listens only to IP 127.0.0.1
> for incoming SMTP connections and accepts my box's user as the only
> other destination for
> which mail is accepted.
>
> As I am on a wired ADSL connection and have "always on" web access,
> "Dial-on-Demand"
> configuration is disabled.
>
> Is there a way I can avoid the "Starting MTA:" delay at boot?
>
> Thanks in advance,
>
> JHM

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi,

D?a Wed, 10 Nov 2021 14:25:13 -0300 Fabio Martins via Exim-users
<exim-users@exim.org> napísal:

> to see what it is querying, add those entries to /etc/hosts in the
> exim-machine

mostly items from /etc/mailname and /etc/hostname are enough to start
exim "normally" ;-)

eg:

127.0.0.1 localhost <mailname> <hostname>

regards

--
Slavko
https://www.slavino.sk

> > The problem is that my DNS (unbound) runs on the Devuan ascii
> > virtual machine which I set up to start up automatically at boot but
> > it is not yet up and running when Exim4 does the reverse DNS check.

> Well, this is the sort of problem systemd is supposed to avoid :-)

In case the queries cannot be served from local zones, even if the name
server is up, it may be unable to answer the query successfully if its
peers or the network to them is down.

This is a typical problem with many Unix applications: If DNS was down
while the system started, things fail in weird ways. Resolving the
service dependencies only solves the common case.

In the old days, people put queries to be resolved while booting in a
hosts map. I always recommend to check a system by starting it without
network connection to see what happens.

Michael

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hello:

On 10 Nov 2021 at 11:29, Evgeniy Berdnikov via Exim-users wrote:

> ... not yet up and running when Exim4 does the reverse DNS check.

The problem was not caused by the VBox VM / Exim4 starting order but
by Exim4's default configuration / installation process / whatever.

ie: Exim4 was not waiting for the virtual machine to start but was
*obviously* attempting to do something and not being able to do it,
generating a 30s (timed) delay in the boot sequence.

I did not want to but finally ended up diving into the Exim4
configuration files.

I followed your instructions to change the 30s value on
daemon_startup_sleep but that did not solve the problem.

While I was at it, I also tried playing with the reverse DNS values,
including remming the whole reverse DNS block, also to no avail.

This left me with the impression that the problem (30s delay) was not
at all related to the reverse DNS done by Exim4 or the
daemon_startup_sleep value.

A last minute complete reinstall of Exim4 (typical MS strategy I
really loathe) did not work either.

tl;dr

The solution was to add 'this' line to the the 'Main' section of the
file exim4.conf.template:

disable_ipv6 = true

But I had to add it: it was *not* there by default.

ie: not disable_ipv6 = false, disable_ipv6 = true or even
disable_ipv6 = so it would be an option when running dpkg-reconfigure
exim4-config.

I was just shooting in the dark, no memory of how I got to doing
that. It was late, I was tired, cannot remember.

Probably the paniclog message I had not seen before?
ie: IPv6 socket creation failed: Address family not supported by
protocol

It can be reproduced: remming the line added to exim4.conf.template
will bring back the delay and the message in the paniclog.

In any case, I am of the opinion that this is a bug in Exim version
4.92 #5.

Why? Because this is happening even after a clean Exim4 installation
on Devuan Beowulf with IPv6 disabled everywhere:

1.
The kernel command line includes the bit needed to disable ipv6 at
boot:

ipv6.disable=1

2.
The /etc/hosts file has no machine readable IPv6 lines:

groucho@devuan:~$ cat /etc/hosts
#
127.0.0.1 localhost devuan
#
# remmed to disable ip6
#::1 localhost ip6-localhost ip6-loopback
#fe00::0 ip6-localnet
#fe00::0 ip6-mcastprefix
#fe02::1 ip6-allnodes
#fe02::1 ip6-allrouters
groucho@devuan:~$

3.
The /etc/ssh/ssh_config file includes the line needed to disable
ipv6:

groucho@devuan:~$ cat /etc/ssh/ssh_config
--- snip ---
AddressFamily inet # instead of 'any' or 'inet6'
--- snip ---
groucho@devuan:~$

That was it.

Exim4 was attempting to do something on IPv6 but not being able to do
it.

This in spite of IPv6 being disabled at the kernel command line,
/etc/hosts and /etc/ssh/ssh_config.

The end result being a 30s delay at boot.

Thanks a lot (to all) for your input.

Best,

JHM
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hello:

On 10 Nov 2021 at 11:29, Evgeniy Berdnikov via Exim-users wrote:

> ... not yet up and running when Exim4 does the reverse DNS check.

The problem was not caused by the VBox VM / Exim4 starting order but
by Exim4's default configuration / installation process / whatever.

ie: Exim4 was not waiting for the virtual machine to start but was
*obviously* attempting to do something and not being able to do it,
generating a 30s (timed) delay in the boot sequence.

I did not want to but finally ended up diving into the Exim4
configuration files.

I followed your instructions to change the 30s value on
daemon_startup_sleep but that did not solve the problem.

While I was at it, I also tried playing with the reverse DNS values,
including remming the whole reverse DNS block, also to no avail.

This left me with the impression that the problem (30s delay) was not
at all related to the reverse DNS done by Exim4 or the
daemon_startup_sleep value.

A last minute complete reinstall of Exim4 (typical MS strategy I
really loathe) did not work either.

tl;dr

The solution was to add 'this' line to the the 'Main' section of the
file exim4.conf.template:

[code]
disable_ipv6 = true
[/code]

But I had to add it: it was *not* there by default.

ie: not disable_ipv6 = false, disable_ipv6 = true or even
disable_ipv6 = so it would be an option when running dpkg-reconfigure
exim4-config.

I was just shooting in the dark, no memory of how I got to doing
that. It was late, I was tired, cannot remember.

Probably the paniclog message I had not seen before?
ie: IPv6 socket creation failed: Address family not supported by
protocol

It can be reproduced: remming the line added to exim4.conf.template
will bring back the delay and the message in the paniclog.

In any case, I am of the opinion that this is a bug in Exim version
4.92 #5.

Why? Because this is happening even after a clean Exim4 installation
on Devuan Beowulf with IPv6 disabled everywhere:

1.
The kernel command line includes the bit needed to disable ipv6 at
boot:

[code]
ipv6.disable=1
[/code]

2.
The /etc/hosts file has no machine readable IPv6 lines:

[code]
groucho@devuan:~$ cat /etc/hosts
#
127.0.0.1 localhost devuan
#
# remmed to disable ip6
#::1 localhost ip6-localhost ip6-loopback
#fe00::0 ip6-localnet
#fe00::0 ip6-mcastprefix
#fe02::1 ip6-allnodes
#fe02::1 ip6-allrouters
groucho@devuan:~$
[/code]

3.
The /etc/ssh/ssh_config file includes the line needed to disable
ipv6:

[code]
groucho@devuan:~$ cat /etc/ssh/ssh_config
--- snip ---
AddressFamily inet # instead of 'any' or 'inet6'
--- snip ---
groucho@devuan:~$
[/code]

That was it.

Exim4 was attempting to do something on IPv6 but not being able to do
it.

This in spite of IPv6 being disabled at the kernel command line,
/etc/hosts and /etc/ssh/ssh_config.

The end result being a 30s delay at boot.

Thanks a lot (to all) for your input.

Best,

JHM
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

JHM via Exim-users <exim-users@exim.org> (Fr 12 Nov 2021 22:14:12 CET):
> [code]
> disable_ipv6 = true
> [/code]

Shooting into the dark as well. If IPv6 is enabled, Exim tries to
resolve names as A and as AAAA records. Independend on your system's IPV6
setup.

The gethostinfo(3) depends on your system's setup and doesn't even
attempt AAAA lookups if there is no chance to use the information, but
in parts of the code Exim doesn't rely on the gethostinfo(3) call, but
talks directly to the resolver (found in /etc/resolv.conf).

So, if you resolver behaves strange (imposing a 30s delay by e.g. not
responding to AAAA queries), the root cause of delay is outside of Exim,
while disable_ipv6 = true is a good mitigation.

--
Heiko

Hello:

On 13 Nov 2021 at 11:50, Heiko Schlittermann via Exim-users wrote:

> JHM via Exim-users <exim-users@exim.org> (Fr 12 Nov 2021 22:14:12 CET):
> > [code]
> > disable_ipv6 = true
> > [/code]
>
> Shooting into the dark as well. If IPv6 is enabled, Exim tries to
> resolve names as A and as AAAA records. Independend on your system's
> IPV6 setup.
Yes, that's probably it.
But it is the cause of the problem.

In my opinion as desktop end user, if the box where Exim is being
installed does *not* have IPv6 enabled (and is explicitly disabled), then
it should *not* be configured by default with IPv6 enabled.

What I think would be a good idea is that at installation time ie: when
dpkg-reconfigure-exim4-config runs, the installer looks to check if IPv6
is configured or maybe just ask if IPv6 is to be configured.

And not assume that it should be enabled by default.
I think we're quite a few years from IPv6 being used by default
everywhere.

eg: just reading the kernel command line to see if the ipv6.disable=1 bit
is present would be quite enough for a basic check to decide how to
configure Exim when installing.

Adding the /etc/hosts file to the files to read would add yet a second
layer of certainty.

At the very least, adding the line I added to the exim4.conf.template with
the proper comments would have been of great help to me.

I spent a great many hours attempting to solve this problem.
Could have been avoided. 8^ )

> ... but in parts of the code Exim doesn't rely on the gethostinfo(3)
> call, but talks directly to the resolver (found in /etc/resolv.conf).

My name server (Unbound) runs on a VBox virtual machine which also runs
Pi-hole:

[code]
groucho@devuan:~$ cat /etc/resolv.conf
nameserver 192.168.1.4
groucho@devuan:~$
[/code]

Just like the host, the virtual machine has IPv6 explicily disabled in the
same way. IPv6 is also disabled in my ADSL router. So, no IPv6 *anywhere*.

> So, if you resolver behaves strange ...
> ... the root cause of delay is outside of Exim ...

I beg to differ.

Exim was installed on a machine with IPv6 disabled, like I have pointed
out, from the kernel command line onwards.

If it installed with IPv6 enabled by default on such a machine, I cannot
but conclude that the problem is with the Exim installation routine and
not elsewhere.

> .... disable_ipv6 = true is a good mitigation.
It was the solution to the problem, one which could easily be avoided.

Many thanks for your input.

Best,

JHM
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 13 Nov 2021, at 13:14, JHM via Exim-users <exim-users@exim.org> wrote:
> What I think would be a good idea is that at installation time ie: when
> dpkg-reconfigure-exim4-config runs, the installer looks to check if IPv6
> is configured or maybe just ask if IPv6 is to be configured.

That’s a downstream (Debian and derivatives) issue, as that’s specific to those distributions.

Not an Exim issue, specifically, but if you want that check in your packages, please report it to the maintainer.

Graeme

Hi.

On Sat, Nov 13, 2021 at 10:14:34AM -0300, JHM via Exim-users wrote:
> In my opinion as desktop end user, if the box where Exim is being
> installed does *not* have IPv6 enabled (and is explicitly disabled), then
> it should *not* be configured by default with IPv6 enabled.

Note that we are discussing some hypothesis, more or less plausible,
but there are no direct confirmations that problem is due to IPv6.

You have better to obtain strace/ltrace and/or extented debug output,
plus traffic dump and/or DNS logs for analysis.
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hello:

On 13 Nov 2021 at 18:10, Evgeniy Berdnikov via Exim-users wrote:

> ... we are discussing some hypothesis ...
Yes, I agree.

> ... no direct confirmations that problem is due to IPv6.
Well ...

First I have the Exim paniclog message which gave me a clue as to what could have been
going on.

[code]
IPv6 socket creation failed: Address family not supported by protocol
[/code]

Then I have that adding the line below to the 'Main' section of the exim4.conf.template file
gets rid of both the delay *and* the paniclog message:

[code]
disable_ipv6 = true
[/code]

And lastly I have that I can faithfully reproduce the problem by simply rolling back the edit.
As expected, the rollback brings back both the delay *and* the paniclog message.

Seems as confirmed as can be.
At least to me.

Thanks for your input.

Best,

JHM

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 13/11/2021 15:50, JHM via Exim-users wrote:
> IPv6 socket creation failed: Address family not supported by protocol

The trouble is that this error only tell us that this specific
socket create failed. Inferring that the system as a whole has
no ipv6 support would be a bit of a step.

We could use some way of enquiring of the system for such configuration,
if not too invasive in the exim binary - and flip the default for the
disable_ipv6 option. I'm not aware if there is any such method.
Please also be aware that Exim run on, and has to be built and tested for,
not only other Linux distros but also other non-Linux Unixes.

Or, as has been suggested, the Debian installer could do the same
configuration change. Or you could, if it was your choice to
configure this system without ipv6.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hello:

On 13 Nov 2021 at 16:35, Jeremy Harris via Exim-users wrote:

> On 13/11/2021 15:50, JHM via Exim-users wrote:
> > IPv6 socket creation failed: Address family not supported by protocol

> Inferring that the system as a whole has no ipv6 support would be a bit of a step.
Unless, as is this specific case, all the necessary steps to disable IPv6 have been taken.

See: https://lists.exim.org/lurker/message/20211112.211353.fde57a1f.en.html

IPv6 is explicitly disabled on the host system at the kernel command line, at the /etc/hosts file
and the /etc/ssh/ssh_config file.

The virtual machine running the DNS on the host system is configured in the very same
manner and the ADSL router also has it's IPv6 capacity administratively disabled.

So, there's no IPv6 in the system or anywhere near it because I disabled it.
No inferring so no step. <- just "taking the piss", so to speak. =^)

Exim makes a call when it starts up and sits there waiting to get an answer that it will not
receive for the reasons stated above.

Why does it do that?

Because it installed with IPv6 enabled by default.

By adding a line to disable it in exim4.conf.template the problem was no longer a problem.
The 30s delay was no more and I had no more /var/log/exim4/paniclog entries.

> We could use some way of enquiring of the system ...
Sure ...

Check the kernel command line when installing and see if there's a ipv6.disable=1 stanza in
it.
That would be more than enough.

Or ask at installation time if IPv6 should be enabled.

> ... and flip the default for the disable_ipv6 option.
Like I suggested in a previous post:

Add the line I *had* to add to the 'Main' section of the
file exim4.conf.template:

[code]
disable_ipv6 = true
[/code]

It is not there.

ie: not disable_ipv6 = false, disable_ipv6 = true or even disable_ipv6 = with an empty value
so it would be an option to fill in when running dpkg-reconfigure exim4-config.

> ... not aware if there is any such method.
Neither am I.

I'm just a desktop end user who came across a problem and asked about it here.

> ... be aware that Exim run on, and has to be built and tested for,
> not only other Linux distros but also other non-Linux Unixes.
Of course.

> Or, as has been suggested, the Debian installer could do ...
The Debian chaps won't do absolutely anyhing about this.

> Cheers,
Same to you.

Thanks a lot for your input.
Have a good week-end.

Best,

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 13/11/2021 21:18, JHM via Exim-users wrote:
> On 13 Nov 2021 at 16:35, Jeremy Harris via Exim-users wrote:
>
>> On 13/11/2021 15:50, JHM via Exim-users wrote:
>>> IPv6 socket creation failed: Address family not supported by protocol
>
>> Inferring that the system as a whole has no ipv6 support would be a bit of a step.
> Unless, as is this specific case, all the necessary steps to disable IPv6 have been taken.
>
> See: https://lists.exim.org/lurker/message/20211112.211353.fde57a1f.en.html
>
> IPv6 is explicitly disabled on the host system at the kernel command line, at the /etc/hosts file
> and the /etc/ssh/ssh_config file.
>
> The virtual machine running the DNS on the host system is configured in the very same
> manner and the ADSL router also has it's IPv6 capacity administratively disabled.
>
> So, there's no IPv6 in the system or anywhere near it because I disabled it.
> No inferring so no step. <- just "taking the piss", so to speak. =^)

Wrong.

From that error return from that syscall, one would have to be making
an inference that the system had ipv6 disabled, to justify taking action
to not perform ipv6 actions in the rest of Exim. Exim doe not know
that there is no ipv6 in the system, nor that you disabled it.

>
> Exim makes a call when it starts up and sits there waiting to get an answer that it will not
> receive for the reasons stated above.
>
> Why does it do that?
>
> Because it installed with IPv6 enabled by default.

Actually because your configuration left it enabled.

>
> By adding a line to disable it in exim4.conf.template the problem was no longer a problem.
> The 30s delay was no more and I had no more /var/log/exim4/paniclog entries.
>
>> We could use some way of enquiring of the system ...
> Sure ...
>
> Check the kernel command line when installing and see if there's a ipv6.disable=1 stanza in
> it.
> That would be more than enough.

You can provide code to do this? Which still compiles cleanly on other
platforms? And the testing, added to the regression testsuite, to ensure
it carries on working into the future?

> Or ask at installation time if IPv6 should be enabled.

The Exim project does not install Exim into your system. The support
for doing that is provided by you distro - I think you said Devuan.
You need to go ask them for this feature to be added to their distro.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hello:

On 13 Nov 2021 at 22:09, Jeremy Harris via Exim-users wrote:

> > So, there's no IPv6 in the system or anywhere near it because I disabled it.
> Wrong.

I must insist on this:
IPv6 is explicitly disabled on the host, the virtual machine and the ADSL router.
*I* disabled it.

> Exim doe not know that there is no ipv6 in the system, nor that you disabled it.
Exactly.
It does not know and behaves accordingly.

> Actually because your configuration left it enabled.
If by *my* configuraton you mean the exim4.conf.template file, yes.
I've been saying that from the very start.

> The Exim project does not install Exim into your system.
> The support for doing that is provided by you distro ...
> You need to go ask them for this feature to be added to their distro.
I see.

I have been (from the start), under the impression that the installer was an Exim thing.
Which is why I posted here asking about the problem.

If the exim4.conf.template file is the distribution's resposibility and not Exim's, then I'll have to
see about this elsewhere.

Thanks so much for the heads up and for your input.

Have a good week-end.

Best,



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sat, Nov 13, 2021 at 08:07:36PM -0300, JHM via Exim-users wrote:
> On 13 Nov 2021 at 22:09, Jeremy Harris via Exim-users wrote:
>
> > > So, there's no IPv6 in the system or anywhere near it because I disabled it.
> > Wrong.
>
> I must insist on this:
> IPv6 is explicitly disabled on the host, the virtual machine and the ADSL router.
> *I* disabled it.

You blindly belive that all your actions lead to expected results.
But it's better to check and prove it, rather then belive.
Show us values of the kernel variables controlling IPv6 operation.

> > Exim doe not know that there is no ipv6 in the system, nor that you disabled it.
> Exactly.
> It does not know and behaves accordingly.

There is nothing wrong to use IPv6-related calls if IPv6 is disabled.
In this case they should return errors and application should process
them in proper way (disable ipv6 code paths, or do something similar).
If you insist that Exim behaves wrong, you have to provide clear evidence
of such misbehaviour.

> > Actually because your configuration left it enabled.
> If by *my* configuraton you mean the exim4.conf.template file, yes.
> I've been saying that from the very start.

Again, we are discussing some hypothesis on the configuration level, but
there were no direct proofs (strace, etc) that problem is related to IPv6.
Facts from network API or code level would help to locate the source.
--
Eugene Berdnikov

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

JHM via Exim-users <exim-users@exim.org> wrote:

> I have been (from the start), under the impression that the installer was an Exim thing.
> Which is why I posted here asking about the problem.
>
> If the exim4.conf.template file is the distribution's resposibility and not Exim's,

See https://wiki.debian.org/Exim .
It could be Devuan makes similar statements.

--
u34

> then I'll have to
> see about this elsewhere.
>
> Thanks so much for the heads up and for your input.
>
> Have a good week-end.
>
> Best,
>
>
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi,

D?a Sat, 13 Nov 2021 20:07:36 -0300 JHM via Exim-users
<exim-users@exim.org> napísal:

> Hello:
>
> On 13 Nov 2021 at 22:09, Jeremy Harris via Exim-users wrote:
>
> > > So, there's no IPv6 in the system or anywhere near it because I
> > > disabled it.

> I must insist on this:
> IPv6 is explicitly disabled on the host, the virtual machine and the
> ADSL router. *I* disabled it.

We live in 2021, IPv6 is reality and important part of countries are
using it [1] (except my one :-P ) and most of nowadays OS enables it by
default for long time.

I meet IPv6 problem a long ago, and i still use one server (currently
debian oldstable) which has IPv6 disabled by default. But it has IPv6
disabled only due historical reasons from time when i had problem with
DNS A/AAAA queries (more than 10 years ago) and i do only minimal
required setting changes at upgrade on it. It is intended only for
intranet services (DNS cache, LDAP, etc) and has exim too, which acts
as LAN smarthost... And AFAIK, most (if not all) of that LAN computers
(and servers) has IPv6 support enabled. It works with IPv4 only
Internet access and it works for hundreds users and nobody complains (i
am employer's admin).

On Linux, there are multiple was how to deal with IPv6, it can be built
in kernel (where mentioned boot option is to disable it), but it can be
loaded as module too, where not loading it is enough to disable IPv6.
Even with buil-in support, it can be disabled in /proc FS and again no
cmdline is needed. In other words, detecting boot parameter can be
enough for OP, but it is not universal and better option approach
exist. BTW, there is 10 years old bug report about missing IPv6 and
exim in debian [2] & [3], and some info and links are in [4] too.

Nowadays i consider to disable IPv6 support as bad practice. i have no
DNS problems, even with software not supporting IPv6, nor to get AAAA
responses, nor to deal with IPv6 communication, except with services
which provides AAAA, but does not respond on it (but that is another
story). IPv6 autoconfiguration works fain, even in IPv4 only networks
and modern software can properly deal with it in that setup...

I consider as normal behavior to expect that IPv6 support is enabled in
system in present days in default configuration, as it is enabled by
default in OS. If someone does non default things, one have to do
it in software too and do not expect, that someone other will do his
home work.

The debian (and thus devuan too) is distribution intended for
experienced Linux admins and it is not intended to provide defaults
which works in all cases, nor which works in best manner (and in same
rare cases nor which works at all :-D) It is expected, that admins will
customize services to fit his own needing. If that doesn't work for OP,
perhaps it is not best distribution for he/she.

regards

[1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610918
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999612
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747324

--
Slavko
https://www.slavino.sk

Hello:

On 14 Nov 2021 at 12:01, Evgeniy Berdnikov via Exim-us wrote:

> > IPv6 is explicitly disabled on the host, the virtual machine and the ADSL router.
> > *I* disabled it.
> ... blindly belive that all your actions lead to expected results.
> ... better to check and prove it ...
> Show us values of the kernel variables ...

Well ...
I don't think I have to go as far as values of the kernel variables. 8^D
Would not have idea as to where to look.

But I *do* have it directy "from the Exim's mouth", so to speak.
It is in the paniclog:

[code]
IPv6 socket creation failed: Address family not supported by protocol
[/code]

Without any editing of the exim4.conf.template file, I invariably got that paniclog message:
(yes, I am now aware that this file is a matter for Debian packagers to solve)

Adding the line disable_ipv6 = true to the the 'Main' section of the exim4.conf.template file
immediately solved the problem I was having.

ie: no 30s delay and no panic log message.

Rolling back the edit to the file got the expected result:

ie: a 30s delay at boot delay and the same panic log message.

I have no reason to doubt what Exim is reporting.

> If you insist that Exim behaves wrong ...
No.
I never said such a thing.

What I have said all along is that Exim was configured to use IPv6 by default.

Posting about the issue here set the record straight, explaining how Exim/Linux
configurations were set.

That said, I'd like to thank all who posted in reply to my queries and end my participation in
this thread.

It has been quite enlightening.

Best,


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

JHM via Exim-users <exim-users@exim.org> (So 14 Nov 2021 11:43:17 CET):
> Hello:
>
> [code]
> IPv6 socket creation failed: Address family not supported by protocol
> [/code]

IMHO that's not the reason for a 30s delay.

> Without any editing of the exim4.conf.template file, I invariably got that paniclog message:
> (yes, I am now aware that this file is a matter for Debian packagers to solve)
>
> Adding the line disable_ipv6 = true to the the 'Main' section of the exim4.conf.template file
> immediately solved the problem I was having.
>
> ie: no 30s delay and no panic log message.

Yes, this (again IMHO) disables queries for AAAA records. But, repeating
myself, I suppose, that a correctly working resolver should respond to
such queries immediatly. No matter, if you've IPv6 enabled or not.

And Exim, in case it got an IPv6 adress for a host to connect to, should
get an immediate "connection refused" or similar error from your host's
OS and then retry the other addresses (IPv4 being among them) without
any delay.

Please provide logs, strace output or tcpdump PCAP files captured during
the startup phase of Exim.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -