I'm having a bit of an issue with Nginx silently failing on restart on Centos6.
If Nginx is running, service nginx restart will stop it, without actually restarting it.
Yet it outputs:
Checking configuration of nginx: [ OK ]
Stopping nginx: [ OK ]
Starting nginx: [ OK ]
Again, it says nginx is started successfully, yet a status check shows that it isn't. If nginx is already stopped, though, service nginx restart will work. Consequently a double restart will restart it.
The error.log for accompanying the output above only has:
2015/03/03 21:53:17 [notice] 14093#0: signal process started
Any thoughts as to why this is happening?
reload does not have this same problem. Is it swappable with restart when config changes are made?
Related
I have Alpine Linux, 3.15.0 version on the server.
The installed nginx version is 1.21.6. I have performed apk update
nginx -t command successfully responds with
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
When I type nginx -s reload server responds with
2023/02/03 10:58:00 [notice] 54#54: signal process started
but nothing actually happens. It's like the process started and that's all.
What am I missing?
According to Nginx documentation, command nginx -s reload actually sends signal to nginx master process and
once the master process receives the signal to reload configuration,
it checks the syntax validity of the new configuration file and tries
to apply the configuration provided in it. If this is a success, the
master process starts new worker processes and sends messages to old
worker processes, requesting them to shut down.
Thus, we can consider that nginx is restarted (If we disregard the fact that the master process itself continued to work).
At the same time, if you want to totally restart nginx, you can stop it with nginx -s quit command and then start again. Or that's much better use your system service manager. If I'm not mistaken, there is an open-rc in Alpine, thus command will be rc-service nginx restart.
I have installed on Fedora 35 jfrog-artifactory-oss (v7.31.11-73111900.x86_64) and enabled it as a system service to start at boot. But whenever I boot up my OS, the server never starts properly. I will always need to kill the PID of the active running Artifactory process. If I then do sudo service artifactory restart it will bring up the server cleanly and everything is good. How can I avoid having to do this little dance? Is there something about OS boot up that is causing Artifactory to get thrown off?
I have looked at console.log when the server is not running properly after bootup, I see some logs like:
2022-01-27T08:35:38.383Z [shell] [INFO] [] [artifactoryManage.sh:69] [main] - Artifactory Tomcat already started
2022-01-27T08:35:43.084Z [jfac] [WARN] [d84d2d549b318495] [o.j.c.ExecutionUtils:165] [pool-9-thread-2] - Retry 900 Elapsed 7.56 minutes failed: Registration with router on URL http://localhost:8046 failed with error: UNAVAILABLE: io exception. Trying again
That shows that the server is not running properly, but doesn't give a clear idea of what to try next. Any suggestions?
2 things to check,
How is the artifactory.service file in the systemd directory
Whenever the OS is rebooted, what is the error seen in the logs, check all the logs.
Hint: From the warning shared, it seems that Router service is not able to start when OS is rebooted, so whenever OS is rebooted and issue comes up check the router-service.log for any errors/warnings.
I have followed few blogs on implementing the restart service for nginx without sudo using my User ID. I completed all the steps as mentioned in blogs. But while am re-starting the Nginx Services without sudo am facing the below error.
**Command Used :**
/usr/bin/systemctl restart nginx
**Log:**
Failed to restart nginx.service: Interactive authentication required.
See system logs and 'systemctl status nginx.service' for details.
**Reference:**
https://stackoverflow.com/questions/51019993/restart-stop-nginx-using-my-userid-without-sudo-permissions/51020325#51020325
https://askubuntu.com/questions/692701/allowing-user-to-run-systemctl-systemd-services-without-password
https://serverfault.com/questions/69847/linux-how-to-give-a-user-permission-to-restart-apache
Please help on resolving the error and restart nginx without sudo
I have OSX El Capitan. I installed Nginx-Full via homebrew. I am supposed to be able to start and stop services with
brew services Nginx-Full Start
I run that command and it seems to start no problem. I check the running services with
brew services list
That indicates that the Nginx-Full services is running. When i run
htop
to look at everything that is running Nginx does not show up and the server is not handling requests.
nginx is failing to launch because of an error, but brew-services is not communicating that to you.
Running it with sudo, as other users have suggested, is just masking the problem. If you just run nginx directly, you may see that there is actually a configuration or permissions issue that is causing nginx to abort. In my case, it was because it couldn't write to the error log:
nginx: [alert] could not open error log file: open() "/usr/local/var/log/nginx/error.log" failed (13: Permission denied)
2020/04/02 13:11:53 [warn] 19989#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /usr/local/etc/nginx/nginx.conf:2
2020/04/02 13:11:53 [emerg] 19989#0: open() "/usr/local/var/log/nginx/error.log" failed (13: Permission denied)
The last error is causing nginx to fail to launch. You can make yourself the owner of the logs with:
sudo chown -R $(whoami) /usr/local/var/log/nginx/
This should cause subsequent config errors to be written to the error log, even if homebrew services is not reporting them in stderr/stdout for now.
I've opened an issue about this: https://github.com/Homebrew/homebrew-services/issues/215
The log path may not the same for everyone. You can check the path to log file by checking the config file /usr/local/etc/nginx/nginx.conf. You can find a line like:
error_log /Users/myusername/somepath/nginx.log;. Change the chown command above accordingly. If even this didn't solve the problem, you may have to do the same for any other log files specified in the server blocks in your nginx configuration
Try launching it with "sudo", even if the formula say
The default port has been set in /usr/local/etc/nginx/nginx.conf to 8080 so that
nginx can run without sudo.
sudo brew services Nginx-Full start
this worked for me:
sudo brew services start nginx
Running sudo nginx worked for me, it initially gave some error stating certain file in certain directory is missing, creating that file, and then another file is asked for to be created and then it runs properly.
I had similar problem, running it brew services start nginx used to show nginx running.
but brew services list used to show error.
running with sudo nginx solved my issue
Did google and various other search engines but still could not sort it out.
Here is my scenario:
Larave 5 on homestead
1) ps -eo pid,comm,euser,supgrp | grep nginx
[following is the output ]
2333 nginx root root
2335 nginx vagrant adm,cdrom,sudo,dip,www-data,plugdev,lpadmin,sambashare,vagrant
2) Based on some search result, did make the following on : /etc/php/7.0/fpm/pool.d
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
3) Output with sudo service php7.0-fpm restart
Restarting PHP 7.0 FastCGI Process Manager php-fpm7.0 [ OK ]
4) Output with sudo service nginx restart
nginx stop/waiting
nginx start/running, process 2650
5)output with :
sudo /etc/init.d/nginx restart
Restarting nginx nginx [fail]
6)output with: tail -f /var/log/nginx/error.log
> 2015/12/26 15:35:23 [notice] 2088#2088: signal process started
2015/12/26 15:45:23 [notice] 2266#2266: signal process started
2015/12/26 15:45:23 [alert] 2095#2095: *9 open socket #3 left in connection 5
2015/12/26 15:45:23 [alert] 2095#2095: aborting
2015/12/26 15:49:02 [alert] 2303#2303: *1 open socket #3 left in connection 3
2015/12/26 15:49:02 [alert] 2303#2303: aborting
2015/12/26 16:00:39 [notice] 2475#2475: signal process started
2015/12/26 16:02:25 [notice] 2525#2525: signal process started
2015/12/26 16:03:08 [notice] 2565#2565: signal process started
2015/12/26 16:14:45 [notice] 2645#2645: signal process started
`
I am just having bad time with this 502 Bad Gateway
> nginx/1.9.7
and php
> PHP 7.0.1-1+deb.sury.org~trusty+2 (cli) ( NTS )
`
If anyone can please help me move on with this situation, that would be great. And, thank you in advance.
Finally solved this here. I want to thank Miguel from laracast discussion.
You need to change your configuration file under:
/etc/nginx/sites-enabled
change line fastcgi_pass for
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
php7.0-fpm.sock is located under:
/var/run/php
Since the new VM uses php 7.* and your configuration file might have the php location for 5.6 version.
Then restart Nginx and PHP
sudo service nginx restart
sudo service php7.*-fpm restart
7.3 and the xdebug version in Homestead 8..* are incompatible. Further info found here*
try this in /etc/php/7.0/fpm/pool.d/www.conf
listen.owner = nginx
listen.group = nginx
listen.mode = 0660
finally restart php7.0-fpm
service php7.0-fpm restart
I've got same error, 502 Bad Gateway (Ngix 1.blablabla)
It's EASY to solve it.
just type into your terminal.
if your VM is running:
vagrant reload --provision
else:
vagrant halt
and later:
vagrant up --provision
I had the same problem ... and solved it in an easy way:
If you use composer, just replace old:
laravel/homestead (v2.*)
with:
laravel/homestead (v3.0.1)
If you change the sites property after provisioning the Homestead box, you should re-run vagrant reload --provision to update the Nginx configuration on the virtual machine.
Here is my story I installed fresh latest homestead and try to run my Laravel 5.4 project but after a day of debugging so gave custom php for my project . This is how it work.
1. vi Homestead.yaml
2. sites:
- map: homestead.test
to: /home/vagrant/code/my-project/public
php: "7.1"
php 7.1 works from Laravel 5.4 to 5.7
3. vagrant up --provision