You are not logged in.
Hello:
Like mentioned in another thread, I am running Pi-Hole v5.6 - FTL v5.11 - Web Interface v5.8 on a virtual machine as a recursive DNS for my Linux box.
The Devuan ascii virtual machine is set up to start up automatically when I boot.
I have set the cache on Pi-hole to a value of '0' so caching is all done by Unbound.
It uses the default list and I have added others.
The rig is not kept on 24/07 but is booted up a few times every 24 hours.
From what I can see it is working properly and Pi-Hole diagnostics declare no issues 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 is doing a check on something.
After a delay of ~30/40s, the MTA resumes loading and then exim4 starts and everything works as expected.
ie: after it finds the virtual machine.
I then log in and have to wait a bit for Pi-hole to come up and start working, but it is just 5s, so no big deal.
But the 30/40s delay at boot is rather annoying.
Exim4 wants to see the virtual machine, seems it is to do a reverse DNS lookup which can only do if the VM is up and running.
I have not been able to find a way for exim4 to not do this.
Now, nothing tries to send email to this system.
The MTA only receives system messages which help me keep tabs on what is going on. eg: crontab failures, warnings from other applications.
I would like to avoid having to delve into Exim4's innards which are a real nightmare.
Is there a way to make VBox start the VM sooner and maybe delay exim4?
Thanks in advance,
A.
Offline
Hello:
... a (not too) short delay at "Starting MTA:" ...
... (as I understand it) Exim4 is doing a check on something.
... a way to make VBox start the VM sooner and maybe delay Exim4?
Rather dissapointed to see that I'm probably the only one here using Pi-hole on a VM. 8^P
But I digress, so to the point:
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.
Hence the delay at boot.
I really did not want to but finally ended up diving into the Exim4 configuration files.
On the suggestion of a (very kind) member of the exim-users list, I was given instructions for changing 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 come up (?) 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?
In any case, to me this is another Exim4 bug.
I see it as a bug because this is happening even after a clean Exim4 installation on a Devuan installation 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:~$
So that was it, Exim4 was attempting to do something on IPv6 but not being able to do it.
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.
Have a good week-end.
Best,
A.
Last edited by Altoid (2021-11-12 16:35:02)
Offline