FS#64587 - [nginx][nginx-mainline]: update service file with Wants=network-online.target

Attached to Project: Arch Linux
Opened by Tim (bastelfreak) - Wednesday, 20 November 2019, 11:24 GMT
Last edited by Massimiliano Torromeo (mtorromeo) - Saturday, 16 September 2023, 09:23 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Massimiliano Torromeo (mtorromeo)
Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
T.J. Townsend (blakkheim)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
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 https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/#cutthecraphowdoimakesurethatmyservicestartsafterthenetworkisreallyonline. 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
-After=network.target network-online.target nss-lookup.target
+After=network-online.target nss-lookup.target


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

Closed by  Massimiliano Torromeo (mtorromeo)
Saturday, 16 September 2023, 09:23 GMT
Reason for closing:  Implemented
Additional comments about closing:  nginx-1.24.0-2
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" network-online.target (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 network-online.target really enforce something like systemd-networkd? As far as I understand, network-online.target only depends on network.target 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 network-online.target, 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 network-online.target was reached immediately after network.target, without any target in between.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.
Comment by Massimiliano Torromeo (mtorromeo) - Saturday, 16 September 2023, 09:22 GMT
Using "Wants=network-online.target" is consistent with many other services used by arch and other distros in this context