Issue nginx can't start automaticaly after server reboot

[azz]

Good day.
My server: Debian 7.11‬, Plesk Onyx Version 17.5.3 Update #6, apache 2.2.22, nginx 1.11.10

Some times ago all was ok. After last update i understand, that nginx can't start on system boot, but i can start them manualy:

root@vmi:~# /etc/init.d/nginx status
[FAIL] nginx is not running ... failed!
root@vmi:~# /etc/init.d/nginx restart
[ ok ] Restarting NGINX: nginx.

root@vmi:/# cat /var/log/nginx/error.log
2017/05/22 13:08:34 [emerg] 2039#0: bind() to [2a02:c207:2007:320::1]:80 failed (99: Cannot assign requested address)
2017/05/22 13:08:34 [emerg] 2170#0: bind() to [2a02:c207:2007:320::1]:80 failed (99: Cannot assign requested address)

root@vmi:/# chkconfig nginx
nginx  on

systemd is not install in my system, and i don't want install it

I was reading a lot of forums and articles, including this:
https://talk.plesk.com/threads/nginx-wont-start-after-reboot.339588/
https://talk.plesk.com/threads/nginx-wont-start-automatically-after-reboot.314493/
How to enable Nginx reverse proxy in Plesk

All of them isn't work. Also, i can't see nginx in plesk services:

It is production server with 23 sites, so i can't be very brave in my experiments. But also i don't want to do "service nginx restart" after every server reboot. Please, help me with this trouble.

 

[Bitpalast]

The solution is presented in my response to https://talk.plesk.com/threads/nginx-wont-start-after-reboot.339588/ . The reason for the behavior is that at the time when Nginx shall start, the network interfaces are not yet ready. Nginx cannot bind to the port at that time. You must let the startup of Nginx wait until the interfaces become available. The easiest way to do that is to add a sleep timer to the startup routine as described. This is not caused by Plesk and cannot be solved via the Plesk software. It is an OS issue.

 

[mr-wolf]

I've been running this script for a while and it hasn't bitten me yet

I just create a symbolic link in /etc/cron.5min/ (you need to create that in /etc/crontab first)

ln -s /usr/local/sbin/watch-process /etc/cron.5min/watch-nginx

The name of the process is taken out of the symbolic link.
It can only manage services that run as a user with that same name (at least the first 6 letters).
Some code is there to minimize the chance of it reacting on the wrong process.
It's working for everything I am using it for thus far....

grep cron.5min /etc/crontab

*/5  *  *   *   * root   cd / && run-parts /etc/cron.5min

cat /usr/local/sbin/watch-process

#!/bin/sh

PROCESS="`echo $0 | grep -o 'watch-.*' | cut -b7-`"
THIS_SCRIPT="`readlink $0`"
SCRIPTNAME=${THIS_SCRIPT##*/}

if [ -z "${PROCESS}" ] ; then
  echo "Wrong usage: make a symbolic link to ${THIS_SCRIPT} named watch-<service>" >&2
  exit 1
elif [ "watch-${PROCESS}" = "${SCRIPTNAME}" ]  ; then
  echo "Wrong usage: make a symbolic link to ${THIS_SCRIPT} named watch-<service>" >&2
  exit 1
fi

USER="`echo ${PROCESS} | awk -F- '{print $1}' | cut -b1-7`"
USERID="`grep "^${USER}" /etc/passwd | awk -F: '{print $3}'`"
SEARCH="`echo ${PROCESS} | tr - .`"
SERVICE=`find /etc/init.d/ -maxdepth 1 -type f | grep ${SEARCH} | head -n1`

if ! grep -q ${USER} /etc/passwd ; then
  echo "${USER} does not exist, service is not installed" >&2
  exit 1
fi
if [ -z "${SERVICE}" ] ; then
  echo "${SERVICE} is not installed as service" >&2
  exit 1
elif [ ! -x ${SERVICE} ] ; then
  echo "${SERVICE} is a DISABLED service" >&2
  exit 1
fi

ps aux | egrep "^(${USER}|${USERID} )" | grep -q " .*${SEARCH}" && exit 0

echo "`date +%b' '%d' '%H:%M:%S` Watchdog $0 invokes \"${SERVICE} start\"" | tee -a /var/log/${SCRIPTNAME}.log >&2

${SERVICE} start

 

[Bitpalast]

Thank you for this input. It makes sense. Let me please add something important:
a) Check for the existance of the substring "httpdmng" in any process
b) Check for the existance of the substring "letsencrypt" in any process
If either of these exist in the process list, neither stop, start or restart Nginx, nor Apache. If you do while httpdmng or letsencrypt updaters are reconfiguring web server configurations it will most likely disrupt www service.
Further, in our surveillance scripts, we test with "nginx -t" and "apachectl -t" that the configuration of both are "OK" before we execute an auto-restart, because else a restart will fail leaving www service inactive, too.

 

[mr-wolf]

Thank you for this input. It makes sense. Let me please add something important:
a) Check for the existance of the substring "httpdmng" in any process
b) Check for the existance of the substring "letsencrypt" in any process
If either of these exist in the process list, neither stop, start or restart Nginx, nor Apache. If you do while httpdmng or letsencrypt updaters are reconfiguring web server configurations it will most likely disrupt www service.

I agree with all of the above, but I don't think it should be made part of such a script.
Just a manual check before applying it...

Further, in our surveillance scripts, we test with "nginx -t" and "apachectl -t" that the configuration of both are "OK" before we execute an auto-restart, because else a restart will fail leaving www service inactive, too.

It's not a restart, but a start. The process is not running anyhow.

I have a seperate monitoring program (Zabbix) that checks if services are running.
No long-term problem can remain undetected...
The watchdog is merely there to minimize the chance of users knowing it ever was down.