Me deparei com essa situação semelhante e foi porque a porta já estava sendo usada por outro serviço.
Como eu descobri isso?
Tente executar
sudo nginx
em vez de iniciá-lo como um serviço e deve exibir a mensagem de erro.
Eu tenho um servidor que está perto de novo e tendo um problema com a obtenção do nginx para iniciar como esperado. Eu configurei outro servidor basicamente da mesma forma e ele funciona lá. Eu acho que deve haver alguma diferença ambiental entre os dois, mas não consegui encontrá-lo.
A versão curta:
Starts - sudo nginx
Fails - sudo service nginx start
Fails - sudo service nginx restart
works - sudo service nginx stop
Quando os comandos falham, eles não dizem nada além de:
* Restarting nginx nginx [fail]
Nada mais nos arquivos de log (nginx [acesso ou erro], syslog) ou escrito na tela
Mais detalhes:
Ambos dizem que o arquivo de configuração está OK
sudo service nginx configtest
sudo nginx -t
Eu verifiquei as permissões do nginx.conf e elas estão OK (o mesmo que o servidor em funcionamento) Verifiquei duas vezes se o www-data tinha acesso aos arquivos de log e tal e faz
O arquivo /etc/init.d/nginx é o mesmo em ambos os servidores, assim como o comando usado (veja acima)
Os arquivos de log existem
usuário / grupo www-data existe
Ubuntu 12.04 LTS
nginx 1.6
Executou o nginx service - sudo strace request iniciado em cada erver Além da primeira parte abaixo, as únicas outras diferenças que vi entre a execução nos dois servidores diferentes eram coisas como ponteiros e o PID. Eu prefixei as duas linhas por conjunto que são diferentes com ***
==== O que funciona
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) = ?
=============== O que falha
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) = ?
Me deparei com essa situação semelhante e foi porque a porta já estava sendo usada por outro serviço.
Como eu descobri isso?
Tente executar
sudo nginx
em vez de iniciá-lo como um serviço e deve exibir a mensagem de erro.
Esta não será uma resposta muito satisfatória ou popular, mas é o que encontrei.
Parece que o mecanismo inicial é muito sensível a condições externas que vão além do que o próprio nginx estava preocupado.
Desde que eu tive uma medida paliativa de iniciar o nginx fora do upstart, continuei atualizando meu servidor. Quando se tratava de reiniciar o nginx para ter certeza de que estava usando o ambiente atual, usei "sudo service nginx restart" para parar o atual e depois inseri manualmente o comando start que falhou no script upstart (a parada funcionou foi o início que falha). Depois de fazer isso por um tempo e atualizar subdomínios e arquivos a serem servidos junto com outras pequenas coisas, abruptamente. o "sudo service nginx restart" funcionou. Em nenhum momento o comando manual do nginx ou os comandos "sudo service nginx restart" colocaram quaisquer erros / avisos que eu encontrei.
Tudo o que posso pensar é que deve ter havido alguma condição que estava abaixo do limite para colocar qualquer tipo de erro ou aviso que incomodasse o upstart, mas não o nginx. Embora fosse o suficiente para fazer com que ele falhasse, não se incomodou o suficiente para colocar qualquer mensagem real sobre o motivo pelo qual estava falhando. Arrgh!
Os arquivos de log e os diretórios pai são de propriedade ou legíveis por www-data ? Os arquivos e diretórios e diretórios pais que você deseja veicular são de propriedade ou legíveis por www-data ?
Você pode tentar strace. Se assim for executado:
sudo strace service nginx start
que produzirá muitos resultados. Em algum lugar perto do final, você provavelmente verá um erro de permissão. Pode ser mais fácil salvar a saída strace em um arquivo e passar por isso.
Outra opção seria alternar para o usuário www-data e verificar se você recebe algum erro ao ler / gravar manualmente os arquivos de log ou ler os outros arquivos que deseja veicular. Mesmo se www-data tiver um shell ruim, você pode fazer:
sudo su -s /bin/bash www-data
Se você executar whoami nesse shell, ele deverá dizer www-data .
Você pode tentar usar o seguinte trabalho do Upstart e ver se isso faz alguma diferença:
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
Tags upstart nginx ubuntu-12.04