Bug 144400

Summary:

[patch] /etc/rc.d/named - $named_wait_host needs an upper bound

Product:

Base System

Reporter:

andy wilson <wilson.andrew.j>

Component:

conf

Assignee:

Mark Linimon <linimon>

Status:

Closed Overcome By Events

Severity:

Affects Only Me

CC:

linimon, ml

Priority:

Normal

Version:

8.0-RELEASE

Hardware:

Any

OS:

Any

See Also:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231193

Bug Depends on:

Bug Blocks:

231193

Attachments:

Description	Flags
file.diff	none

Description andy wilson 2010-03-01 21:50:02 UTC

If you set $named_wait_host to a remote hostname and something is going wrong with the name resolution process for that particular hostname, your system will hang indefinitely. Some services (like ntpd) depend on being able to resolve remote DNS hostnames, but you would still want the system to come up if it is having trouble resolving $named_wait_host.

It would help to have an additional variable that specifies an upper bound for how long /etc/rc.d/named spends attempting to resolve $named_wait_host. That way $named_wait_host can be set to a remote hostname but your system will not be completely dependent on that hostname successfully resolving.



This addition would make it easy to solve problems like the one discussed here:  http://forums.freebsd.org/showthread.php?t=9171

Fix: I've attached patches for /etc/rc.d/named and /etc/defaults/rc.conf ; these patches add and document an optional $named_wait_max variable that sets the maximum number of seconds that rc.d/named will wait while trying to resolve $named_wait_host.

Patch attached with submission follows:
How-To-Repeat: Set up rc.conf with the following variables:

ntpd_enable="YES"
named_enable="YES"
named_wait="YES"
named_wait_host="someunresolvablehostname.somenonexistentdomain.com"


Then run: 
/etc/rc.d/named restart

Comment 1 andy wilson 2010-03-01 23:30:09 UTC

I misfiled this; it should have been filed in conf.  Sorry about that.

Comment 2 Mark Linimon freebsd_committer

2010-03-02 00:36:42 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-rc

Fix category and assign.

Comment 3 Mark Linimon freebsd_committer

2010-03-13 21:38:46 UTC

Responsible Changed
From-To: freebsd-rc->dougb

dougb has volunteered to look at named bugs.

Comment 4 Doug Barton freebsd_committer

2010-03-13 21:45:11 UTC

State Changed
From-To: open->closed


I've thought about your PR for a while, and my conclusion is that the 
current setting is doing what it's designed to do. If name resolution 
is critical to the system's function, subverting the _wait option is 
not what we should be doing. If it isn't critical, the user would not 
have set that option in the first place (which defaults to off btw).  

I will keep your PR on record in case this issue resurfaces down the 
road. Meanwhile, thanks for your interest in making FreeBSD better. 


Doug

Comment 5 Ian Lepore freebsd_committer

2018-09-06 20:07:23 UTC

I believe it was an error to reject this patch. A problem exists and needs a fix like this for the reasons stated when the bug was opened.  However, I believe the default behavior should be to wait forever unless the user specifically configures some timeout value.  I'm reopening this because it's potentially the fix for bug 231193.

Comment 6 Graham Perrin freebsd_committer

2022-10-17 12:37:09 UTC

Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>

Comment 7 Mark Linimon freebsd_committer

2023-08-22 20:13:52 UTC

With a heavy heart, return this PR to rc@ with bugmeister hat.

To Andy: is this aging PR still relevant?

Comment 8 andy wilson 2023-08-23 04:58:13 UTC

> To Andy: is this aging PR still relevant?


It is not still relevant to me, personally. I don't know if it's still a failure mode / bug that exists today and is worth fixing.