yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #90624
[Bug 1998621] [NEW] dnsmasq on DHCP Agent does not listen on tcp/53 after dnsmasq restart
Public bug reported:
When talking to dnsmasq using DNS over tcp dnsmasq will fork out for TCP
connections. Forked processes will stay until all connections have been
closed, meaning that dangling connections will keep the processes and
with that will also keep the tcp/53 port in listening state. On dnsmasq
restart (e.g. on network update, subnet create, ...) the parent process
is killed with SIGKILL and a new process is started. This new process
cannot listen on tcp/53, as it is still in use by the old child with the
dangling connection.
This could be prevented by sending SIGTERM instead of SIGKILL, as
dnsmasq then does a proper cleanup of its forks and all tcp/53
connections are properly closed.
This only happens when starting the dnsmasq with --bind-dynamic, as with this flag dnsmasq will ignore any errors resulting form it not being able to bind on tcp/53, see here:
https://github.com/imp/dnsmasq/blob/f186bdcbc76cd894133a043b115b4510c0ee1fcf/src/network.c#L725-L726
The flag has been introduced here:
https://bugs.launchpad.net/neutron/+bug/1828473
** Affects: neutron
Importance: Undecided
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1998621
Title:
dnsmasq on DHCP Agent does not listen on tcp/53 after dnsmasq restart
Status in neutron:
In Progress
Bug description:
When talking to dnsmasq using DNS over tcp dnsmasq will fork out for
TCP connections. Forked processes will stay until all connections have
been closed, meaning that dangling connections will keep the processes
and with that will also keep the tcp/53 port in listening state. On
dnsmasq restart (e.g. on network update, subnet create, ...) the
parent process is killed with SIGKILL and a new process is started.
This new process cannot listen on tcp/53, as it is still in use by the
old child with the dangling connection.
This could be prevented by sending SIGTERM instead of SIGKILL, as
dnsmasq then does a proper cleanup of its forks and all tcp/53
connections are properly closed.
This only happens when starting the dnsmasq with --bind-dynamic, as with this flag dnsmasq will ignore any errors resulting form it not being able to bind on tcp/53, see here:
https://github.com/imp/dnsmasq/blob/f186bdcbc76cd894133a043b115b4510c0ee1fcf/src/network.c#L725-L726
The flag has been introduced here:
https://bugs.launchpad.net/neutron/+bug/1828473
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1998621/+subscriptions
Follow ups