Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#64587 - [nginx][nginx-mainline]: update service file with

Attached to Project: Arch Linux
Opened by Tim (bastelfreak) - Wednesday, 20 November 2019, 11:24 GMT
Last edited by Toolybird (Toolybird) - Monday, 02 January 2023, 00:43 GMT
Task Type Feature Request
Category Packages: Extra
Status Assigned
Assigned To Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


I've nginx and also nginx-mainline deployed on a few hundred boxes. They are supposed to bind to specific ip addresses. Sometimes during a reboot this fails because the ip address isn't available yet. I checked the systemd documentation at They recommend the following change:

$ git diff
diff --git a/repos/community-x86_64/service b/repos/community-x86_64/service
index 365bc95..ef00027 100644
--- a/repos/community-x86_64/service
+++ b/repos/community-x86_64/service
@@ -1,6 +1,7 @@
Description=A high performance web server and a reverse proxy server


Additional info:
* package version(s)

1.17.4-1 nginx-mainline and also 1.16.1-1 nginx

* config and/or log files etc.

nginx[803]: 2019/07/01 11:04:26 [emerg] 803#803: bind() to *myip*:9100 failed (99: Cannot assign requested address)

* link to upstream bug report, if any

Steps to reproduce:

reboot a server with nginx very often
This task depends upon

Comment by Giancarlo Razzolini (grazzolini) - Thursday, 21 November 2019, 22:53 GMT
My main issue with this is that it makes the nginx process contingent on having a wait service. This also means that we're enforcing the usage of one of the network managers that do have this.
Comment by Jonas Hahnfeld (hahnjo) - Monday, 16 March 2020, 10:18 GMT
Finally got around to debugging my warnings about '"ssl_stapling" ignored, host not found in OCSP responder'. I think this is also due to this issue: nginx doesn't "Want" (only orders after it) and no other unit does, so it's not enabled at all. Adding a drop-in with "Want" solves the issue because it makes sure that the local unbound can resolve the OCSP domain.

Does "Want"ing really enforce something like systemd-networkd? As far as I understand, only depends on and other services (for example systemd-networkd-wait-online.service) MAY add themselves "Before" the target.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 16 March 2020, 17:20 GMT
It requires having a service that reaches, yes. As far as I know, most network managers support that. Also, this is a double edged sword, if the network never comes online, nginx won't work start at all.
Comment by Jonas Hahnfeld (hahnjo) - Monday, 16 March 2020, 21:37 GMT
Are you sure that this is still true in recent versions of systemd? I just booted a server without activating systemd-networkd-wait-online.service and was reached immediately after, without any target in between.