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)                           = ?
1
  • 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? May 19, 2015 at 21:33

4 Answers 4

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.

3
  • Thanks for the tip but that was one of the first things I checked. The plain sudo nginx was my alternative start that worked. It gave no error message, Thats why it was so strange Dec 3, 2014 at 0:16
  • 1
    This was super useful. I didn't know this command. Thank you.
    – Ken Prince
    Mar 16, 2015 at 14:10
  • This is very useful; it reveals the error message I was searching for. May 3, 2015 at 2:39
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!

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.

4
  • 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 Aug 4, 2014 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" Aug 5, 2014 at 15:17
  • Something weird must be going on in the start script. Does it look like gist.github.com/squarism/3400259 ??
    – chicks
    Aug 5, 2014 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 Aug 6, 2014 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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .