Possible bug - hostname-defined upstream locations, bind addresses, etc. from /etc/hosts not referenced at some load times

Maxim Dounin mdounin at mdounin.ru
Sun May 17 04:18:26 UTC 2015


On Fri, May 15, 2015 at 04:51:38PM -0400, Thomas Ward (Dark-Net) wrote:

> Long subject, I know, but this has been noticed in NGINX 1.6.x, 1.7.x,
> 1.8.x, and my 1.9.x from-source builds.
> The documentation for 'listen', 'upstream' blocks, and many other
> things does state hostnames are usable in binding and proxying.  While
> this is very understandable, I think we have a few issues in there,
> perhaps even bugs.
> At some system boots, /etc/hosts is not read or interpreted by nginx.
> Therefore, I run into resolution issues for addresses that are defined
> in teh local /etc/hosts file.  Running nginx as a service *after* a
> reboot seems to make the binding work, but this is an issue that has
> cropped up multiple times downstream on bugs on my radar in Debian and
> Ubuntu, and even on my own packaging of the nginx source code.  I've
> also replicated it on the nginx.org repository as well.
> Is there some way to enforce nginx checking the /etc/hosts?  Or is
> this just a system boot time race condition where nginx tries to load
> before /etc/hosts and the underlying system/kernel DNS handling (which
> states that /etc/hosts has resolution or such) isn't initiated yet?

To resolve names during configuration parsing nginx uses 
gethostbyname() or getaddrinfo() functions.  It's up to the 
OS to provide appropriate service.  That is, what you describe 
looks like a system startup race condition.  I'm not really 
familiar with Debian/Ubuntu, but may be adding $named to 
Required-Start list in the init script will fix things.

Maxim Dounin

More information about the nginx-devel mailing list