Error nginx restart failed

Иногда в дата центрах производится обновление оборудования с вынужденной сменой локального ip. Вследствии чего nginx перестает работать с ошибкой:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] bind() to 10.8.121.203:80 failed (99: Cannot assign requested address)
nginx: configuration file /etc/nginx/nginx.conf test failed

Я расскажу как быстро все исправить на сервере с установленной VestaCP.

Узнаем новый локальный ip

В том случае если у вас VestaCP. Заходим в панель, вверху переходим по ссылке “IP”. Там выбираем существующую запись со старым ip и нажимаем “reread IP”. Теперь VestaCP знает новый ip и мы тоже.

Другой вариант, если у вас нет VestaCP.

Вводим в консоли ifconfig или более современный вариант ip addr show и получаем такой ответ:

eth0      Link encap:Ethernet  HWaddr de:2e:4c:1f:60:2d
          inet addr:10.19.82.89  Bcast:10.19.82.89  Mask:255.255.255.254
          inet6 addr: fe80::dc2e:4cff:fe1f:602d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:186354 errors:0 dropped:0 overruns:0 frame:0
          TX packets:166552 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24624828 (24.6 MB)  TX bytes:185543285 (185.5 MB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:71602 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71602 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:50340449 (50.3 MB)  TX bytes:50340449 (50.3 MB)

Там видим, что наш новый локальный ip – 10.19.82.89

Замена старого ip на новый

Теперь ищем все упоминания старого ip в файлах конфигурации. Для этого вводим в консоли

# grep -rl 10.8.121.203 /etc
/etc/apache2/mods-enabled/remoteip.conf
/etc/apache2/mods-enabled/rpaf.conf

Меняем во всех найденных файлах старый ip на новый. То же для папки /usr. Если grep ничего не находит в папке /usr, то это нормально для VestaCP – она сама внесла изменения

find /home ( -name "*.conf" ) -type f -exec sed -i 's/10.8.121.203/10.19.82.89/g' {} ;

Команда выше меняет ip во всех файлах конфигурации в папке /home.

Остается перезапустить apache и nginx

apachectl restart
service nginx restar

Nginx start fail with no errors

I can’t start my nginx (1.6.2) on Debian using service nginx start. I have 0 error, only FAIL as message.

I checked my config using nginx -c /etc/nginx/nginx.conf -t and it’s successfull.

I have built nginx from source, I have installed pagespeed module.

It seems I have the same error from here : https://stackoverflow.com/questions/24961066/cant-start-nginx-no-errors-anywhere But after checked, both files are looking for /run/nginx.pid. This file seems to be empty thought, is this a problem ?

ls -al /run/*.pid give me :

When I use ps -A , I have 2 nginx with 2 pid differents. Is this the problem ?

Something weird too, when I access my IP in web browser, I have the «Welcome to Ningx» message. But, service nginx status returns FAIL.

1 Answer 1

Having several nginx process might be normal. or not. If you only have 2 processes, then you probably have the master process and 1 worker process, which is the way nginx works. Having several master processes, unless it is what you wish, is probably sign of trouble.

If your PID file is empty, that is definitely a problem: it is used by the managing service to identify which process to check for and to send signals to. Empty PID file = service will try to send signals to the void.

Using ps -ef|grep -E «(PID|nginx)»|grep -v grep , try to identify the master process (that is the one with PPID 1 and calling itself ‘master in its description). Then send it a TERM, KILL or QUIT signal.

Manually remove the PID file

Check your service file (if you use init, it is most probably /etc/init.d/nginx ) for the PID file name and compare it to the location you provided

Ensure no PID file is there, no nginx process runs anymore and use your service normally to start/stop/reload/check status again.

That should do it.

Now, where does that empty PID file comes from is an interesting question one could ask him/herself. Have you played around with it? Multiple instances of nginx does not apply for it, you should have something there!

Источник

nginx not restarting

I installed nginx on my Ubuntu 18.04. After that I made some changes in the default file. Now I am trying to start it but I am getting following error:

Somebody please guide me how to restart the nginx.

3 Answers 3

It seems as if your Port 80 is blocked. ( nginx: [emerg] bind() to 0.0.0.0:80 failed ) Try:

to find out which process is blocking the port, kill the programm/service and restart nginx.

I’d also advice you to run nginx -t as the user nginx is running as, so the

gives you a clear indication on wether there actually is a problem writing the logfile. Running this as your standard user may lead to incorrect results if you don’t have the same access rights as for example the http user.

First validate that the configuration files are valid:

Apply the changes without restarting the Nginx service:

If the changes are not applied immediately, restart the service with the following command (unlike the command used in the previous step, it will abruptly close all web client connections):

In the extreme case, you can kill the process and start it again with:

In some cases Nginx may fail to restart because some child processes or another process (Apache or httpd) are using port 80 or 443. In these cases I recommend stopping Nginx ( sudo systemctl stop nginx ) and validate if any process continues to listen in the port 80:

You can see more details with:

To see the running processes more easily you can use htop .

When nobody is using the TCP/80 port, you can start Nginx again:

Источник

Nginx не стартует, но проверка конфига не показывает ошибок?

Nginx 1.12.0, Linux RH 7.2
Установил, сделал конфиг — проверка конфига выдает что все ок:

nginx: the configuration file /etc/nginx/conf.d/ev1.conf syntax is ok
nginx: configuration file /etc/nginx/conf.d/ev1.conf test is successful

Запускаю, выдает ошибку:

systemctl start nginx.service
Job for nginx.service failed because the control process exited with error code. See «systemctl status nginx.service» and «journalctl -xe» for details.

Starting nginx — high performance web server.
nginx: [emerg] «events» directive is not allowed here in /etc/nginx/conf.d/ev1.conf:1
nginx: configuration file /etc/nginx/nginx.conf test failed
nginx.service: control process exited, code=exited status=1

Запускаю со стандартным конфигом — запускается без ошибок. Возвращаю конфиг — снова ошибки. Как понять что не так с конфигом (тест конфига проходит нормально).

• Вопрос задан более трёх лет назад
• 36253 просмотра

«events» directive is not allowed here in /etc/nginx/conf.d/ev1.conf:1

Erelecano Oioraen: ой да ладно, не говорите за всех. дефолтный конфиг от убунты 16.04.2 годичной давности.
За старт несистемных демонов от рута руки еще в детском садике должны отбивать.
вопрос2: а вы чем пользуетесь ??

Erelecano Oioraen: тогда почитайте доки системд по теме от каких пользователей стартует ExecStart при наличии настроек User=www-data

ps aufxw|grep nginx

«, all but the listed capabilities will be included, the effect of the assignment inverted. Note that this option also affects the respective capabilities in the effective, permitted and inheritable capability sets, on top of what Capabilities= does. If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced. This option may appear more than once, in which case the bounding sets are merged. If the empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior settings have no effect. If set to «

» (without any further argument), the bounding set is reset to the full set of available capabilities, also undoing any previous settings.

у меня чегой-то не прокатили, мож разберешься ??

Источник

Не стартует Nginx на Ubuntu, в чем может быть дело?

Не стартует nginx на ubuntu 15.04 (x64), уже всю голову сломал вот лог:

Удаление и заново установка не помогают, гугл тоже молчит.

• Вопрос задан более трёх лет назад
• 18360 просмотров

Оценить 4 комментария

Antony Ryabov: Я не очень силен в unix, возможно не правильно смотрю лог.

Я так понимаю это из за того что nginx пытается забиндится на ip 0.0.0.0?

Благодарю за советы, очень удивительно что у меня появился apache. Но дальше я разрулю. Еще раз благодарю за советы =)

Antony Ryabov: Вы бы Ubuntu/Debian подучили.

Команда service как раз создана таким образом, что запускает сервисы вне зависимости от того, какая система инициализации используется. Поэтому /etc/init.d/apache2 и /etc/init/apache2 может не быть, а команда продолжает работать.

Это одна из причин, почему в Ubuntu был один из самых мягких и незаметных для пользователя переходов на systemd, в других дистрах несовместимостей было, на сколько я читал, больше.

Источник

Vesta Control Panel — Forum

nginx restart failed + Letsencrypt

nginx restart failed + Letsencrypt

Post by Felix » Thu Dec 14, 2017 6:33 am

I have an issue with nginx not starting when a domain certificate is updated.

The cron job to renew certificates run at 06:00 each day

When this happens and a certificate is updated, nginx fails to restart with the following error:

Pay attention the the > at the start of the file. This is causing the problem. After editing the file and removing this, nginx restarts fine.

Possible bug?
I think this could be caused by a bug in v-update-letsencrypt-ssl but I can’t be sure. It can also be related to the one added line I place in conf files. I need to redirect https://TLD/email to a different server so I have added the following line inside the server block, below error_log:

Could it be that the addition of the rewrite ^/email$ https://[TLD]:2096/ permanent; is causing this issue?
Can this be resolved in a way compatible with this addition (or any other necessary addition to the conf)?

I understand that I can achieve the same (redirecting https://[TLD]/email) with .htaccess but I wouldn’t like using it, because .htaccess files can be deleted/edited by users and thus break the redirection.

Re: nginx restart failed + Letsencrypt

Post by Felix » Mon Feb 05, 2018 5:43 am

50 days, no reply, nginx still crashing on production servers 🙁

I’d like to add some more info to this issue. Today, one of my domains renewed it’s Let’s Encrypt certificate and as a result nginx crashed. The problem was again the same: a curly bracket broke the syntax of /home/[USER]/conf/web/snginx.conf

What is more interesting is that /home/[USER]/conf/web/snginx.conf is now blank (apart from the curly bracket ofc) and I noticed that there exists a new file /home/[USER]/conf/web/[TLD].nginx.ssl.conf that holds the configuration data for ssl.

Even though now snginx.conf is blank, deleting the file causes problems to nginx (can’t restart because nginx is looking for this file). This is because of /etc/nginx/conf.d/vesta.conf. There are include directives for both /home/[user]/conf/web/snginx.conf and /home/[user]/conf/web/[TLD].nginx.ssl.conf !! But WHY ?!

To sum this up

• The bug is still alive and kicking. When Let’s Encrypt updates certificates, nginx craches!
• Something has changed in the way nginx uses it’s config files

Web Template APACHE2: Hosting
Proxy Support NGINX: Hosting

Re: nginx restart failed + Letsencrypt

Post by noogen » Wed Feb 07, 2018 12:59 am

As you’ve seen it yourself, something has changed. The issue you’re asking about is a known issue and it has been fixed partially. That is why you’re seeing different file for nginx. Your system probably auto updated to Vesta 0.9.8-18

There is a known issue in the way Vesta parses config file for both NGINX and APACHE2. Vesta before v18 store all configs in the same file. The way Vesta does it by counting the number of lines the generated template and cut these lines from nginx or apache conf file. This is error prone. In v18, Vesta start to do this in separate file for NGINX: https://github.com/serghey-rodin/vesta/issues/1447

The issue is that it still can’t parse to remove the old config from the big (multi-domain/site) nginx conf file. Therefore, you may want to backup and then rebuild your user per the github instruction above. Of course this is still an issue with apache conf.

Источник