Facebook
Twitter-
Please be aware: Kaspersky Anti-Virus has been deprecatedWith the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
-
The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
-
We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.
Resolved NGINX not properly started on CentOS 7 even after MU#15;
- Thread starter elcopdoo
- Start date
Any update to this? Seeing same exact issue; fresh install of P12 on CentOS 7, nginx does not start via systemd but starts fine if you manually "systemctl start nginx"
nginx log shows:
2015/07/16 12:01:15 [alert] 3580#0: unlink() "/var/run/nginx.pid" failed (13: Permission denied)
2015/07/16 12:01:41 [emerg] 682#0: bind() to 192.0.2.1:80 failed (99: Cannot assign requested address)
lsof shows nothing bound to that address on port 80. logs show:
Jul 16 11:47:06 serv systemd: Starting Startup script for nginx service...
Jul 16 11:47:06 serv echo: Starting nginx service
Jul 16 11:47:06 serv nginx: nginx: [emerg] bind() to 192.0.2.1:80 failed (99: Cannot assign requested address)
Jul 16 11:47:06 serv nginx: nginx: configuration file /etc/nginx/nginx.conf test failed
Jul 16 11:47:06 serv systemd: nginx.service: control process exited, code=exited status=1
systemctl start nginx works fine.
nginx log shows:
2015/07/16 12:01:15 [alert] 3580#0: unlink() "/var/run/nginx.pid" failed (13: Permission denied)
2015/07/16 12:01:41 [emerg] 682#0: bind() to 192.0.2.1:80 failed (99: Cannot assign requested address)
lsof shows nothing bound to that address on port 80. logs show:
Jul 16 11:47:06 serv systemd: Starting Startup script for nginx service...
Jul 16 11:47:06 serv echo: Starting nginx service
Jul 16 11:47:06 serv nginx: nginx: [emerg] bind() to 192.0.2.1:80 failed (99: Cannot assign requested address)
Jul 16 11:47:06 serv nginx: nginx: configuration file /etc/nginx/nginx.conf test failed
Jul 16 11:47:06 serv systemd: nginx.service: control process exited, code=exited status=1
systemctl start nginx works fine.
I've determined the bug causing this and have filed it with Plesk support.
The issue is twofold:
1) If your server is using ONLY IPv4, then you can fix this by editing the following file:
/etc/systemd/system/multi-user.target.wants/nginx.service
Change this:
After=nss-lookup.target remote-fs.target
to
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
The bug is that Odin has Plesk write out the systemd startup service file without it requiring networking to be online before it can be started. The system boots up, nginx tries to bind to explicit IP addresses which are not up yet, so it fails and doesn't start. You can start it yourself after boot but of course it's down until you do that.
2) If you change the above and things still aren't working, you probably have an IPv6-enabled system; you'll find the error in /var/log/nginx/error_log changes from an IPv4 bind issue to IPv6 bind issue. A RedHat bug allows network-online.target to be met before IPv6 networking is up. So system boots, systemd waits to start nginx until network-online.target is met, starts nginx but IPv6 is not up yet so it still fails.
My stupid solution to this issue is to modify the file further to include this line:
ExecStartPre=/usr/bin/sleep 20
in this order:
ExecStartPre=/bin/echo 'Starting nginx service'
ExecStartPre=/usr/bin/sleep 20
ExecStartPre=/usr/bin/test $NGINX_ENABLED = "yes"
ExecStartPre=/usr/sbin/nginx -q -t
ExecStart=/usr/sbin/nginx
ExecStartPost=/bin/echo "Service nginx started"
it has to come before the nginx -q -t because that also fails before networking is up.
The issue is twofold:
1) If your server is using ONLY IPv4, then you can fix this by editing the following file:
/etc/systemd/system/multi-user.target.wants/nginx.service
Change this:
After=nss-lookup.target remote-fs.target
to
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
The bug is that Odin has Plesk write out the systemd startup service file without it requiring networking to be online before it can be started. The system boots up, nginx tries to bind to explicit IP addresses which are not up yet, so it fails and doesn't start. You can start it yourself after boot but of course it's down until you do that.
2) If you change the above and things still aren't working, you probably have an IPv6-enabled system; you'll find the error in /var/log/nginx/error_log changes from an IPv4 bind issue to IPv6 bind issue. A RedHat bug allows network-online.target to be met before IPv6 networking is up. So system boots, systemd waits to start nginx until network-online.target is met, starts nginx but IPv6 is not up yet so it still fails.
My stupid solution to this issue is to modify the file further to include this line:
ExecStartPre=/usr/bin/sleep 20
in this order:
ExecStartPre=/bin/echo 'Starting nginx service'
ExecStartPre=/usr/bin/sleep 20
ExecStartPre=/usr/bin/test $NGINX_ENABLED = "yes"
ExecStartPre=/usr/sbin/nginx -q -t
ExecStart=/usr/sbin/nginx
ExecStartPost=/bin/echo "Service nginx started"
it has to come before the nginx -q -t because that also fails before networking is up.
U
UFHH01
Guest
A more detailed and professional solution and description is provided by Odin in the Knowledge - Base for the described issues:
Umm, what in that article is a solution to anything?
That's an article that is, first and foremost, an explanation of what systemd is, and then gives some common commands for configuration and debugging. It is not offering a solution to any problem.
It goes on to give an example of a problem seen trying to start nginx, which has absolutely nothing to do with this thread's issue. The example is a failure to bind due to address already in use, meaning something else has already opened port 80 on the example IP 10.39.3.27 for listening.
That has no relation to systemd attempting to start nginx in parallel to network starting, and nginx failing to start because it can't bind to IP addresses that do not yet exist on the server's network interface. It gives no information on how to solve that problem, or even the problem given as an example. It gives no information on how to delay nginx from starting until networking comes up. It gives no information on how to work around the bug in RHEL/CentOS 7 with regard to systemd thinking networking is up when IPv6 is not yet up.
Well, this issue still exists in Plesk 12.0.18 - very annoying.
Better war for IPv4 only enviromentes, because its update-safe.
- mkdir /etc/systemd/system/nginx.service.d
- create file named start-dep-network.conf or something ends with .conf
- add this lines to the newly created file:
- save and do a systemctl daemon-reload
Odin should fix it's unit file for nginx!!!
Better war for IPv4 only enviromentes, because its update-safe.
- mkdir /etc/systemd/system/nginx.service.d
- create file named start-dep-network.conf or something ends with .conf
- add this lines to the newly created file:
Code:
[Unit]
After=network.target remote-fs.target nss-lookup.targetOdin should fix it's unit file for nginx!!!
If you're talking a v4-only environment, there's no need to add an additional conf file since Plesk is already creating the nginx service file to begin with. The fix is the one I posted earlier, just add network-online.target as an After= and Wants=. That ensures nginx doesn't start until IPv4 is fully online; network.target is not sufficient as the addresses may not be available to bind to yet at that point. So that's definitely their bug; they acknowledged that one in my ticket on this.
Unfortunately there is no proper solution for a dual stack environment. The bug is in RHEL7 where network-online.target is considered met before IPv6 is fully initialized, so systemd then starts nginx before it can actually bind to the addresses it's been told to and it fails. Adding a sleep to the startup is the only workaround at this point. Or, Plesk could of course check and start nginx later. Watchdog gets confused by this and doesn't work correctly for some reason.
Yep, but if Odin comes with an update of nginx and its unit file, your fix will be overwritten or you'll have those ugly .rpmnew files there.
So you should never patch existing unitfiles. Better way is to add /etc/systemd/system/nginx.service.d directory and make your changes there.
So you should never patch existing unitfiles. Better way is to add /etc/systemd/system/nginx.service.d directory and make your changes there.
This same problem happens to bind (named) after upgrade as well. This solution fixes both daemons.
Just FYI, it seems RedHat is finally fixing this: https://bugzilla.redhat.com/show_bug.cgi?id=1243958
Enverex
Basic Pleskian
That's actually a different issue, that's a race condition between IPv4 and IPv6 on the RedHat bug tracker.
The original issue is that the Nginx service doesn't wait for the network to come up and will fail if it's not up when it tries to start, so network.service needs to be network-online.service else Nginx will typically fail to start if your machine boots too quickly.
OPs issue is this - https://support.plesk.com/hc/en-us/articles/213398309 - but what doesn't make sense is that article seems to imply it's fixed in Plesk 12 but not 12.5. Why isn't it fixed in 12.5? Either this needs to be fixed in an MU or they (Parallels) need to update the Nginx package (sw-nginx) to contain the fix, considering it's from their repo and packaged by them.
The original issue is that the Nginx service doesn't wait for the network to come up and will fail if it's not up when it tries to start, so network.service needs to be network-online.service else Nginx will typically fail to start if your machine boots too quickly.
OPs issue is this - https://support.plesk.com/hc/en-us/articles/213398309 - but what doesn't make sense is that article seems to imply it's fixed in Plesk 12 but not 12.5. Why isn't it fixed in 12.5? Either this needs to be fixed in an MU or they (Parallels) need to update the Nginx package (sw-nginx) to contain the fix, considering it's from their repo and packaged by them.
