[SOLVED] Problem getting Nginx started on Raspbian

rnturn · 03-08-2021, 11:49 PM

I have a Raspberry Pi running as the Bind server and Nginx server (reverse proxy) on our home LAN. Version: "Raspbian GNU/Linux 9 (stretch)"

Upon booting, Nginx will not start. I've enabled it using systemctl and after rebooting Nginx's error log contains:

Code:

[emerg] 798#798: host not found in upstream "testhost.internal-domain:80" in /etc/nginx/sites-enabled/testhost.internal-domain.conf:5

which, to me, looks like it's not waiting for Bind to be run.

By the time I can get logged in and verify that Nginx is not running, manually executing "/etc/init.d/nginx start" works as it should.

The service file in /lib/systemd/system contains:

Code:

Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target
...

which I changed to be:

Code:

Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
Requires=bind9.service
After=bind9.service
#After=network.target
...

Since "bind9.service" had the same "After=" record, my plan was to let bind wait for the network, than have nginx wait for bind.

I commented out the "After=network.target" record since it seemed logical it seemed logical that, if bind waited for network.target, nginx could simply wait for bind.

After running "systemctl daemon-reload" and booting, though, the same result. Same error message in Nginx's error log. Systemd shows that the nginx service is enabled.

/var/log/syslog contains the error messages:

Code:

nginx[819]: nginx: [emerg] bind() to 192.168.13.178:80 failed (99: Cannot assign requested address)
nginx[819]: nginx: configuration file /etc/nginx/nginx.conf test failed
systemd[1]: nginx.service: Control process exited, code=exited status=1
systemd[1]: Failed to start A high performance web server and a reverse proxy server.
systemd[1]: nginx.service: Unit entered failed state.
systemd[1]: nginx.service: Failed with result 'exit-code'.

Running "nginx -t", "/etc/init.d/nginx configtest", etc. show no problems with the nginx configuration file.

At this point, I've restored the service file using the pre-tweak backup file.

Summary:

At boot: Starting it within Systemd? Does not start nginx.

After boot: "system nginx start"? Starts nginx

After boot: "systemctl start nginx.service"? Starts nginx

... and everything seems to be working after issuing any of the manual commands. (Accessing web sites from the internet does get to the actual servers listening on 8080, etc.)

Ideas as to where to look next?

(I'm trying really hard to be friends with Systemd but every time I encounter a problem with it, I'm seriously tempted to search out a Systemd-free OS for the Pi.)

TIA...

pdean712 · 03-09-2021, 08:41 PM

Code:

nginx[819]: nginx: [emerg] bind() to 192.168.13.178:80 failed (99: Cannot assign requested address)

This emergency error looks to be related to you starting nginx before networking was started...i would try making sure nginx starts After: both networking and bind.

Maybe something like the below:

Code:

After=network.target bind9.service

rnturn · 03-10-2021, 09:07 PM

Quote:

Originally Posted by pdean712

Code:

nginx[819]: nginx: [emerg] bind() to 192.168.13.178:80 failed (99: Cannot assign requested address)

This emergency error looks to be related to you starting nginx before networking was started...i would try making sure nginx starts After: both networking and bind.

Maybe something like the below:

Code:

After=network.target bind9.service

Tried that. No joy. Same error:

Code:

[emerg] bind() to 192.168.13.178:80 failed (99: Cannot assign requested address)

I can start/stop nginx all day long... by hand. "service nginx start", "systemctl nginx start". "/etc/init.d/nginx start"... those all work. It's just Systemd that can't at boot time.

Aha!

I realized that I had troubles getting nginx up and running last summer. The fix at that time was to alter the Unit definition to be:

Code:

[Unit]
#After=network.target
After=multi-user.target

[Install]
#Wants=multi-user.target

It appears that a recent update clobbered that change.

I'll mark this as "solved".