“сервис sudo nginx запускает” сбои, но “sudo nginx” работы - не может выяснить почему
У меня есть сервер, который является близко к новому и имеющему проблемой с получением nginx для запуска как ожидалось. Я настроил другой сервер в основном тот же путь, и он работает там. Я полагаю, что должно быть некоторое экологическое различие между этими двумя, но я не смог найти его.
Короткая версия:
Starts - sudo nginx
Fails - sudo service nginx start
Fails - sudo service nginx restart
works - sudo service nginx stop
Когда команды перестали работать, они ничего действительно не говорят вне:
* Restarting nginx nginx [fail]
Ничто иное в файлах журнала (nginx [доступ или ошибка], системный журнал) или записанный для экранирования
Подробнее:
Оба говорят, что файл конфигурации в порядке
sudo service nginx configtest
sudo nginx -t
Я проверил полномочия на nginx.conf, и они в порядке (то же как рабочий сервер) Проверены дважды, что www-данные имели доступ к файлам журнала и такой, и это делает
/etc/init.d/nginx файл является тем же на обоих серверах и так является используемой командой (см. выше),
Файлы журнала действительно существуют
www-данные пользователя/группы действительно существуют
Ubuntu 12.04 LTS
nginx 1.6
Выполнил требуемый - sudo strace, сервис nginx запускаются на каждом erver Кроме первой части ниже, единственными другими различиями, которые я видел между работой двух различных серверов, были вещи как указатели и PID. Я снабдил префиксом эти две строки на набор, которые отличаются с ***
==== Тот, который работает
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fd6076a09d0) = 24394
close(4) = 0
*** read(3, "/run/nginx.pid\n", 128) = 15
(… snip till the bottom…)
*** rt_sigreturn(0x11) = 24396
dup2(11, 2) = 2
close(11) = 0
read(10, "", 8192) = 0
exit_group(0) = ?
=============== Тот, который перестал работать
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f067e79d9d0) = 21761
close(4) = 0
*** read(3, "/run/nginx.pid\nserver_name\n", 128) = 27
(… snip till the bottom…)
*** rt_sigreturn(0x11) = 21763
dup2(11, 2) = 2
close(11) = 0
read(10, "", 8192) = 0
exit_group(0) = ?
Владельцами или читателями файлов журналов и родительских каталогов являются www-data? Владельцем или читателем файлов и родительских директорий, которые вы хотите обслуживать, являются www-data?
Вы можете попробовать Strace. Если так, то запустите:
sudo strace service nginx start
, что даст много результатов. Где-то в конце вы, вероятно, увидите ошибку в разрешении. Возможно, будет проще сохранить вывод строки в файл и прочитать его.
Другой вариант - переключиться на пользователя www-data и посмотреть, нет ли ошибок при ручном чтении/записи лог-файлов или при чтении других файлов, которые вы хотите обслуживать. Даже если www-data имеет плохую оболочку, вы можете сделать:
sudo su -s /bin/bash wwww-data
Если вы запустите whoami в этой оболочке, в ней должно быть написано www-data.
Это будет не очень удовлетворительный или популярный ответ, но это то, что я нашел.
Похоже, что механизм upstart очень чувствителен к внешним условиям, которые выходят за рамки того, о чем беспокоился сам nginx.
Так как у меня был стоп-гэп запуска nginx за пределами upstart, я продолжил обновление своего сервера. Когда дело дошло до перезапуска nginx, чтобы убедиться, что он использует текущее окружение, я использовал "sudo service nginx restart", чтобы остановить текущее окружение, а затем вручную ввел команду start, которая провалилась в скрипте upstart (стоп сработал, а сбой произошел именно при запуске). После того, как я сделал это некоторое время и обновил обслуживаемые поддомены и файлы, а также другие мелкие вещи, внезапно. "sudo service nginx restart" сработал. Ни в коем случае ни ручной запуск nginx, ни команды "sudo service nginx restart" не выдавали никаких ошибок/предупреждений, которые я мог бы найти.
Все, что я могу придумать, это то, что должно было быть какое-то условие, которое было ниже порога для выдачи любого типа ошибки или предупреждения, которое беспокоило upstart, но не nginx. И хотя этого было достаточно, чтобы сделать его неудачным, оно не настолько беспокоило, чтобы выдать какое-то реальное сообщение о том, почему оно неудачно. Arrgh!
Вы можете попробовать воспользоваться следующим заданием Upstart и посмотреть, имеет ли это какое-либо значение:
description "nginx - small, powerful, scalable web/proxy server"
start on filesystem and static-network-up
stop on runlevel [016] or unmounting-filesystem or deconfiguring-networking
expect fork
respawn
pre-start script
[ -x /usr/sbin/nginx ] || { stop; exit 0; }
exec /usr/sbin/nginx -q -t -g 'daemon on; master_process on;'
end script
exec /usr/sbin/nginx -g 'daemon on; master_process on;'
pre-stop exec /usr/sbin/nginx -s quit
Я столкнулся с подобной ситуацией, потому что порт уже использовался другой службой.
Как я это узнал?
Попробуйте запустить
sudo nginx
, а не запускать его как услуга, и должно отображаться сообщение об ошибке.