After lots of Googling, lots of tracing, lots of tinkering with the nginx.conf & /vhosts -

It came down to an error message saying ClamAV was not up to date. Running clamscan told me clamscan was not installed. Trying to install clamscan told me it was already installed. e_e

So, looks like I'm gonna be wiping this server, soon.

Much thanks to everyone that gave their insight.

If anyone knows a legitimate how or why such a thing can happen, I'd be happy to know...


I solved this by restarting the server. e_e

If I am not mistaken, this would implicate php-fpm -- right?

However, now that nginx is online and responding to the config changes I make -- I'm getting 403 forbidden and 502 bad gateway on things I had never gotten before. (ISPConfig and PhpMyAdmin, respectively) Error log says :

[error] 9150#0: *7 open() "[...]/ispconfig/[..]/phpmyadmin" failed (13: Permission denied), 

One link suggests increasing the buffer size - which I tried, does not work -- And the other things I found seemed to be irrelevant ---

Thanks again !

To make a long story short, this all started when I was trying to make an nginx config to add a password to a site. No big deal - I've done it before, no sweat --

However, the configuration was not working with no good reason as to why ---

Well, long story short, after many failed attempts, I finally commented out the line:

include sites-enabled/* ;

in nginx.conf

Only for the surprise that everything still works ---

After making sure Apache wasn't running (it isn't even installed, anymore!) - I Googled around to see if I could find anything about a config cache on Nginx - but no dice.

So, I've come to you good people, here -- to see if you can lend me any insight on why everything still works against my best intentions of breaking it

Strangely enough, nginx continued to work even after running

sudo service nginx stop
* Stopping nginx nginx


sudo cat /var/log/nginx/error.log 

didn't yield anything useful, aside from the "[emerg] bind() to failed"

Which it seems I've always gotten - and has never caused problems, before...

  • 1
    It sounds like nginx isn't stopping for some reason. You should investigate that, and/or kill it manually before restarting. – Michael Hampton Nov 25 '13 at 16:43
  • It gave me the * Stopping nginx --- Is there a case where that may not actually be the case? – rm-vanda Nov 25 '13 at 17:57

Have you restarted nginx to apply changes?

sudo service nginx restart

Can you try stopping nginx and check that all processes are stopped, before restarting it:

sudo service nginx stop
ps aux|grep nginx # should display no nginx process
sudo service nginx start

If you have "[emerg] bind() to" in logs, check which process is listening to port 80 netstat -anlp|grep 80 and stop it/ or kill it.

| improve this answer | |
  • Yes... I was even going back and forth between reload and restart -- – rm-vanda Nov 25 '13 at 16:32
  • 2
    reload is the better option generally since it won't stop an already running nginx instance if the config is faulty. A restart however will stop the running nginx before starting it again so its possible a faulty config file will prevent it from starting. In this case though it sounds like it isn't running at all so a restart is the correct choice. – Kyle Nov 25 '13 at 17:39
  • 1
    @Kyle agree regarding reload, in this case a process is running on port 80 so I think the better is to stop all, checking that all processes are stopped master&workers, then restart nginx to have a clean instance, after the reload should work as expected – bgentil Nov 25 '13 at 18:27
  • Under further inspection, tripwire and clamav both went MIA-- . So -- some hackery must be at work, here. – rm-vanda Dec 2 '13 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.