“sudo service nginx start”失败,但“sudo nginx”有效——不知道为什么

“sudo service nginx start”失败,但“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[access or error]、syslog)中没有其他内容,屏幕上也没有其他内容

更多细节:

两者都说配置文件没问题

sudo service nginx configtest
sudo nginx -t
  • 我检查了 nginx.conf 的权限,没有问题(与工作服务器相同)。再次检查 www-data 是否有权访问日志文件等,结果确实如此

  • 两个服务器上的 /etc/init.d/nginx 文件相同,使用的命令也相同(见上文)

  • 日志文件确实存在

  • 用户/组 www-data 确实存在

  • Ubuntu 12.04 LTS

  • nginx 1.6

  • 在每个服务器上运行请求的 - sudo strace service nginx start 除了下面的第一部分之外,我看到在两个不同服务器上运行时的唯一其他差异是指针和 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)                           = ?

答案1

我遇到过类似的情况,这是因为该端口已被另一项服务使用。

我怎么发现的?

尝试运行

sudo nginx

而不是将其作为服务启动,它应该显示错误消息。

答案2

这不是一个非常令人满意或受欢迎的答案,但这是我发现的。

看来 upstart 机制对外部条件非常敏感,超出了 nginx 本身所关注的范围。

由于我有一个在 upstart 之外启动 nginx 的权宜之计,所以我继续更新我的服务器。当需要重新启动 nginx 以确保它正在使用当前环境时,我使用“sudo service nginx restart”来停止当前环境,然后手动输入在 upstart 脚本中失败的启动命令(停止成功,但启动失败)。这样做了一段时间并更新了要提供服务的子域和文件以及其他小东西后,“sudo service nginx restart”突然成功了。手动启动 nginx 或“sudo service nginx restart”命令从未发出我能找到的任何错误/警告。

我所能想到的就是,一定存在某种低于发出任何类型的错误或警告的阈值的条件,这困扰了 upstart,但 nginx 却没有。虽然这足以让它失败,但还不足以让它发出任何实际消息来说明失败的原因。啊!

答案3

日志文件和父目录是否由 拥有或可读www-data? 您要提供的文件和目录以及父目录是否由 拥有或可读www-data

你可以尝试 strace。如果可以,请运行:

sudo strace service nginx start

这将产生大量输出。在接近结尾处,您可能会看到权限错误。将 strace 输出保存到文件并通过 grep 进行查看可能会更简单。

另一个选项是切换到用户www-data,看看在手动读取/写入日志文件或读取要提供的其他文件时是否出现任何错误。即使www-datashell 不好,你也可以这样做:

sudo su -s /bin/bash www-data

如果你whoami在该 shell 中运行,它应该说www-data

答案4

您可以尝试使用以下 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

https://bitbucket.org/CameronNemo/upstart-jobs/src/5248c9e3e0f5343bc856ccde380e78c539fbfbe9/nginx.conf?at=master

相关内容