Bug#1000406: nginx-common: Nginx starts before DNS is ready

[Jeremy Ouellet]

Package: nginx-common
Severity: normal

Dear Maintainer,

I was messing with nginx remote proxy and found that it would crash on
startup.
I looked into the service file and it depended on network.target. I
changed it
to network-online.target so that it would work.

I beleive that nginx should wait for the network to be online before
starting
as this makes it so you can use domain names in proxy_pass. I googled
for this
issue and most people just give workarounds and I feel like the use
cases for
using just nework.target are minimal.

-- System Information:
Debian Release: 11.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nginx-common depends on:
ii debconf [debconf-2.0] 1.5.77
ii lsb-base 11.1.0

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
pn fcgiwrap <none>

[Thomas Ward]

We had similar discussions on this type of issue downstream in Ubuntu [1] and after extensive discussions it was suggested that if someone wants to use network-online.target for this they do an override in their SystemD.

Given that network-online.target is not well defined, it was determined by the Ubuntu Server Team that it made more sense to leave it alone and let people 'customize' their configuration that way independently.

Also, keep in mind NGINX Pitfalls such as those that *rely* on DNS - you cannot guarantee that DNS is going to be reliable or work at boot time or auto startup unless you schedule the startup until long after networking would be configured and online.  [2]

While I do not have direct access to control the status quo on things for NGINX in Debian, the justification was based on this quote from the definition of network targets [3]:

network-online.target is a target that actively waits until the network is "up", where the definition of "up" is defined by the network management software. ... **It is strongly recommended not to pull in this target too liberally: for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up), its primary purpose is network client software that cannot operate without network.**

(emphasis with asterisks or bold is mine)

Given that freedesktop definitions for SystemD here say "network server software should generally not pull this in" and NGINX is no different (see pitfalls [2] as I said), I think the 'network.target' vs. 'network-online.target' argument should remain as "If you want to verify it works with DNS then alter your SystemD on a per system level, rather than having the entire packaging system for NGINX to be rewritten for these cases given the SystemD guidance."

Thomas

[1]: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1666368

[2]: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#using-a-hostname-to-resolve-addresses

[3]: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/