[Dnsmasq-discuss] [PATCH] Refuse to start with EADDRINUSE in --bind-dynamic mode
Simon Kelley
simon at thekelleys.org.uk
Wed Nov 22 23:29:41 UTC 2023
Isn't this sufficient to fix the problem?
Not calling die() when bind-dynamic is set is intended to handle the
case that bind returns EADDRNOTAVAIL because you've configured
--listen-address=1.2.3.4 but there's not a local interface with that
address. dnsmasq runs anyway in the expectation that such an interface
will appear in the future and a socket will be bound then.
I don't think there's a die()/syslog() conflict at all.
diff --git a/src/network.c b/src/network.c
index ca9fada..db1d528 100644
--- a/src/network.c
+++ b/src/network.c
@@ -924,7 +924,7 @@ static int make_sock(union mysockaddr *addr, int
type, int dienow)
{
/* failure to bind addresses given by --listen-address at
this point
is OK if we're doing bind-dynamic */
- if (!option_bool(OPT_CLEVERBIND))
+ if (!option_bool(OPT_CLEVERBIND) || errno == EADDRINUSE)
die(s, daemon->addrbuff, EC_BADNET);
}
else
Cheers,
Simon.
On 22/11/2023 19:27, Petr Menšík wrote:
> Hello everyone,
>
> I have received error report RHEL-16398 [1], which I think makes sense
> to fix even in the lastest version. I believe it allows non-intentional
> another instance running without error. What is worse, it does not even
> show any warning that initialization is incomplete.
>
> Of course the problem at start is those errors happen in time when no
> log is available. I think that can be fixed easily by using stderr at
> that time. That is patch #1.
>
> Second makes EADDRNOTAVAIL bind errors still hidden, but prints all
> other errors at least to stderr. On a system with systemd that should
> make it present in journalctl -u dnsmasq anyway. EADDRINUSE is made
> fatal, because that would not be usually handled by new addresses added
> later. If there is a need to start another dnsmasq instance without TCP
> listeners, I think that should be specified more explicitly. Makes
> EADDRINUSE fatal the same way as with --bind-interfaces.
>
> Would you find any other errors, which should be hidden or made fatal?
> What would you think of those changes?
>
> 1. https://issues.redhat.com/browse/RHEL-16398
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
More information about the Dnsmasq-discuss
mailing list