So yesterday I was playing around with our server.

On it we have a docker-compose process running 6 or so containers, one of them being Nginx. Before I played around with it yesterday it was serving files just fine.

What I did

I noticed on DO, that I could upgrade my metrics by running curl -sSL https://agent.digitalocean.com/install.sh | sh. How cool right??

Well after I did that, weird stuff started happening. I cant be sure that it is causation, but it certainly is correlation.

What I tried

I have my DO droplet, and i run docker-compose up -d and I get a :

ERROR: for root_nginx_1 Cannot start service nginx: driver failed programming external connectivity on endpoint root_nginx_1: Error starting userland proxy: listen tcp bind: address already in use

Ok, thats weird...

It was working before and now it wont even start up?

I run ps aux -P | grep nginx to see what going on and get:

root      1514  0.0  0.1 124972  1388 ?        Ss   12:57   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data  1517  0.0  0.2 125332  2960 ?        S    12:57   0:00 nginx: worker process
root      5716  0.0  0.0  12944   940 pts/1    S+   13:16   0:00 grep --color=auto nginx

Hmm, why are there these other nginx processes?

ok, I then run pkill nginx to get rid of them and then again docker-compose up -d and everything startsup fine and dandy, no errors.

However, now when I go to my example.com site, I get no response.

Thinking it might be a config issue, I run docker logs root_nginx_1 and there is NOTHING. There should be at least some headers or requests being logged.

Then in a desperate final attempt I run sudo shutdown -r now and start the whole process over.

Same result with the nginx process running on the server.


  1. Is it normal for this nginx process to be running on the server on startup?
  2. How can I get my nginx container to listen on port 80 without a conflict?
  • 1
    This is why curlpipe-style installs are horrible. Never, ever use them without first 1) examining the source 2) understanding what exactly it's going to do and 3) testing it out on a test system before your production server.
    – EEAA
    Jul 25, 2017 at 13:31
  • Consider my lesson learned. I trusted DO though... Jul 25, 2017 at 13:31
  • There is no way DO nor anyone else can account for every single thing that people might be doing on their servers. It's your responsibility, not theirs.
    – EEAA
    Jul 25, 2017 at 13:33
  • Is it possible that someone (you?) installed nginx on the machine?
    – mhutter
    Jul 25, 2017 at 14:45
  • 1) Ubuntu Docker 17.05.0-ce on 16.04 2) Nope, no one else has access to it. Jul 25, 2017 at 14:56

1 Answer 1


After following the advice of @EEAA and actaully researching what the heck DO Agent was doing, it indeed is using port 80 and 443.

The DigitalOcean Agent uses ports 80 and 443 for outgoing data. Inbound access is not required. Since the Agent only uses the ports for outbound data, you can safely run a web server without interference.

Port 80 is used to contact the DigitalOcean metadata service to obtain an authentication token. The Agent uses this token to authenticate to the metrics backend and encrypt its transmissions.

And after further reading sudo apt-get purge do-agent and sudo rm /etc/apt/sources.list.d/digitalocean-agent.list did the trick.

Here you can, and I recommend you do, read all about it.

  • This sounds weird, this documentation explicitly states that the problems you experienced should NOT happen?
    – mhutter
    Jul 25, 2017 at 14:41
  • Thats what I found strange as well. My thought though is that it had something to do we with issuing localhost:80 as a port and that had a conflict with the background nginx process. Where as, in my limited knowledge of nginx, its usually <ip_address>:80 Jul 25, 2017 at 14:54
  • It depends on the vhost configuration what interface / port a specific vhost uses. Jul 25, 2017 at 16:33

You must log in to answer this question.

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