nginx service start needs to wait dns service

Bug #2023146 reported by NetVicious
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
nginx (Ubuntu)
Triaged
Undecided
Unassigned

Bug Description

When using nginx as reverse proxy you can have one or more upstream server set up with a hostname instead of its IP address like this:

upstream myUpstream {
   server this-host-needs-dns-to-be-resolved.com;
}

If nginx it's started *before* the DNS subsystem it's working nginx won't be started because it cannot resolve the this-host-needs-dns-to-be-resolved.com hostname.

# systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Tue 2023-06-06 06:45:48 CEST; 20s ago
       Docs: man:nginx(8)
    Process: 561 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

Jun 06 06:45:48 ip-172-31-9-7 systemd[1]: Starting A high performance web server and a reverse proxy server...
Jun 06 06:45:48 ip-172-31-9-7 nginx[561]: nginx: [emerg] host not found in upstream "this-host-needs-dns-to-be-resolved.com>
Jun 06 06:45:48 ip-172-31-9-7 nginx[561]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jun 06 06:45:48 ip-172-31-9-7 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Jun 06 06:45:48 ip-172-31-9-7 systemd[1]: nginx.service: Failed with result 'exit-code'.
Jun 06 06:45:48 ip-172-31-9-7 systemd[1]: Failed to start A high performance web server and a reverse proxy server.

To fix this we need to set on systemd some other targets to be waited before the nginx service it's started.

I tried with this change but it doesn't worked.

# diff /etc/systemd/system/multi-user.target.wants/nginx.service /etc/systemd/system/multi-user.target.wants/nginx.service_new
16c16
< After=network.target
---
> After=network-online.target nss-lookup.target

I fixed it setting an ip address on the upstream but I think a simple bug like this should be fixed.

Regards,

Paride Legovini (paride)
tags: added: network-online-ordering
Revision history for this message
Paride Legovini (paride) wrote :

Hello and thanks for your bug report. This is part of a wider category of bugs caused by the fact that some services require network to be "up" to start correctly, but the definition of "network is up" is tricky. The issue is not adding After=network-online.target, but is defining what network-online.target should represent. An approach is being discussed here:

  https://discourse.ubuntu.com/t/spec-definition-of-an-online-system/27838

Changed in nginx (Ubuntu):
status: New → Triaged
Revision history for this message
Robie Basak (racb) wrote :

"DNS subsystem" might mean different things for different people, so I don't think we can introduce a dependency. Otherwise, users who simply use a static DNS configuration would block or break on a DNS subsystem that doesn't exist or is not configured.

Instead, if you configure nginx to your local requirements to add a dependency on a DNS subsystem, I think you currently need to also adjust the nginx service configuration to wait for that subsystem. How to do that depends on your specific setup, but:

> /etc/systemd/system/multi-user.target.wants/nginx.service

Shouldn't this be /etc/systemd/system/nginx.service.wants/something that provides a symlink to whatever "DNS subsystem" means for you? See systemd.unit(5).

Revision history for this message
Thomas Ward (teward) wrote :

also just for information but the nginx wiki actually lists relying on DNS for upstream resolutions as a pitfall you should avoid - see https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#using-a-hostname-to-resolve-addresses

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.