Question 108610 in Ubuntu Question posted in
The official Ubuntu documentation can be found here.

Ubuntu – AWS EC2 instance does not start the nginx service after reboot

I have a Laravel application running on AWS EC2.
I was having an issue with upload_max_filesize and wanted to increase it from the default 2M to 6M. As per php_info(), the php.ini file being used is /etc/php/8.1/fpm/php.ini And I changed the value for upload_max_filesize in this file and restarted the nginx service (not sure if this was enough), but it did not fix the issue. The grep command (grep -r "upload_max_filesize" .) in etc revealed that there are two other files that have the "upload_max_filesize" parameter: /etc/php/8.1/apache2/php.ini and /etc/php/8.1/cli/php.ini and I updated the value for upload_max_filesize in these files too and restarted the nginx service. Though ini_get() was giving me the updated value in php artisan tinker, the php_info() in my app was still displaying 2M. So I decided to reboot the server.

However, after reboot, my website refused to connect:
The site can’t be reached
silkweb.ca refused to connect

On checking the nginx service status, it looks that it is not running, though the nginx configuration is ok

ubuntu@ip-172-31-4-36:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

ubuntu@ip-172-31-4-36:~$ sudo 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 Mon 2023-05-01 17:41:17 UTC; 24min ago
   Docs: man:nginx(8)
    CPU: 63ms

May 01 17:41:15 ip-172-31-4-36 nginx[522]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Unknown error)
May 01 17:41:15 ip-172-31-4-36 nginx[522]: nginx: [emerg] bind() to [::]:80 failed (98: Unknown error)
May 01 17:41:16 ip-172-31-4-36 nginx[522]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Unknown error)
May 01 17:41:16 ip-172-31-4-36 nginx[522]: nginx: [emerg] bind() to [::]:80 failed (98: Unknown error)
May 01 17:41:16 ip-172-31-4-36 nginx[522]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Unknown error)
May 01 17:41:16 ip-172-31-4-36 nginx[522]: nginx: [emerg] bind() to [::]:80 failed (98: Unknown error)
May 01 17:41:17 ip-172-31-4-36 nginx[522]: nginx: [emerg] still could not bind()
May 01 17:41:17 ip-172-31-4-36 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
May 01 17:41:17 ip-172-31-4-36 systemd[1]: nginx.service: Failed with result 'exit-code'.
May 01 17:41:17 ip-172-31-4-36 systemd[1]: Failed to start A high performance web server and a reverse proxy server.
ubuntu@ip-172-31-4-36:~$

Any idea, why nginx is not starting? ( I have rebooted the server a few times, but no luck– everything was working fine before the "upload_max_filesize" change and reboot.)

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    As mentioned by @Rolo787, the nginx service was not able to start because another service (apache) was running which was using the same ports required by nginx. To check if apache service is running:

    sudo systemctl status apache2

    To fix the issue, I stopped the apache service and started nginx:

    sudo systemctl stop apache2
sudo systemctl start nginx

    To disable auto start of the apache service on reboot, use the following command

    sudo systemctl disable apache2

    After running this command, you can check the status of the Apache service to ensure that it is disabled, using the following command:

    sudo systemctl is-enabled apache2

  2. 0

    For anyone referring to this in the future (see comments):

    May 01 17:41:15 ip-172-31-4-36 nginx[522]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Unknown error)
May 01 17:41:15 ip-172-31-4-36 nginx[522]: nginx: [emerg] bind() to [::]:80 failed (98: Unknown error)

    The above indicated that there was a service or process already listening on port 80 causing nginx to fail to bind this port. Looks like this was caused by apache being enabled and binding this port first. Disabling the apache service (or any other services that are interfering) will be the necessary way to go.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search