9

I have a server that is close to new and having a problem with getting nginx to start as expected. I have configured another server basically the same way and it works there. I figure there must be some environmental difference between the two, but I haven't been able to find it.

The short version:

Starts - sudo nginx
Fails - sudo service nginx start
Fails - sudo service nginx restart
works - sudo service nginx stop

When the commands fail they don't really say anything beyond:

 * Restarting nginx nginx                                                [fail]

Nothing else in the log files(nginx[access or error], syslog) or written to screen

More details:

Both say the config file is OK

sudo service nginx configtest
sudo nginx -t

  • I checked the permissions for nginx.conf and they are OK (same as working server) Double checked that www-data had access to the log files and such and it does

  • The /etc/init.d/nginx file is the same on both servers and so is the command used (see above)

  • The log files do exist

  • user/group www-data does exist

  • Ubuntu 12.04 LTS

  • nginx 1.6

  • Ran the requested - sudo strace service nginx start on each erver Other than the first piece below, the only other differences I saw between running on the two different servers were things like pointers and the PID. I prefixed the two lines per set that are different with ***

==== The one that works

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)                           = ?

=============== The one that fails

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)                           = ?
Paul Hardwick
  • 167
  • 1
  • 1
  • 10
  • For the trace, you mention that what you posted were the only differences you saw. Can you actually do a diff between the two outputs to have something more canonical? – Belmin Fernandez May 19 '15 at 21:33

4 Answers4

10

I came across this similar situation and it was because the port was already used by another service.

How I found it out ?

Try running

sudo nginx

rather than starting it as a service and it should display the error message.

Mevin Babu
  • 201
  • 2
  • 5
2

This won't be a very satisfying or popular answer but it's what I found.

It seems that the upstart mechanism is very sensitive to external conditions that go beyond what nginx itself was concerned about.

Since I had a stopgap measure of starting nginx outside upstart, I continued with updating my server. When it came to restarting nginx to make sure it was using the current environment, I used "sudo service nginx restart" to stop the current one and then manually entered the start command that failed in the upstart script(the stop worked it was the start that fails). After doing this for a while and updating subdomains and files to be served along with other small things, abruptly. the "sudo service nginx restart" worked. At no point had the manual start of nginx or the "sudo service nginx restart" commands put out any errors/warnings that I could find.

All I can think of is that there must have been some condition that was below the threshold for putting out any type of error or warning that bothered upstart, but not nginx. While it was enough to make it fail, it didn't bother it enough to put out any actual message as to why it was failing. Arrgh!

Paul Hardwick
  • 167
  • 1
  • 1
  • 10
0

Are the log files and parent directories owned or readable by www-data? Are the files and directories and parent directories you want to serve owned or readable by www-data?

You could try strace. If so run:

sudo strace service nginx start

which will produce a lot of output. Somewhere near the end you will probably see a permission error. It might be easier to save the strace output to a file and grep through that.

Another option would be to switch to the www-data user and see if you get any errors when manually reading/writing the log files or reading the other files you want to serve. Even if www-data has a bad shell you can do:

sudo su -s /bin/bash www-data

If you run whoami in that shell it should say www-data.

chicks
  • 3,639
  • 10
  • 26
  • 36
  • I'm using SUDO so file permissions shouldn't be a problem. At one point I had left off the SUDO and did receive permissions error messages. Also file permissions and user info is the same as the server that works. But I'll take a look – Paul Hardwick Aug 04 '14 at 23:00
  • I checked and updated the question. No permission errors and I included part of the strace output in the question. The main diff was the addition of a server_name to a internally built command "/run/nginx.pid\nserver_name\n" – Paul Hardwick Aug 05 '14 at 15:17
  • Something weird must be going on in the start script. Does it look like https://gist.github.com/squarism/3400259 ?? – chicks Aug 05 '14 at 17:20
  • The init.d file is not identical to your link but similar. It is the same as on another of my severs which does not have the issue – Paul Hardwick Aug 06 '14 at 12:43
-1

You can try to use the following Upstart job and see if that makes any difference:

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

Diamond
  • 8,791
  • 3
  • 22
  • 37
CameronNemo
  • 399
  • 1
  • 6