title: Gitlab Configuration Issues:: NGINX Unicorn Port Conflict
body: <p>I have managed to partly setup <a href="https://github.com/gitlabhq/gitlabhq" rel="nofollow noreferrer">Gitlab</a> on a Linux CentOS server with Apache, Git, PHP, PostGreSQL and MySQL. I am running the <a href="https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/README.md" rel="nofollow noreferrer">Chef Cookbook version</a>. I got the rpm from <a href="https://about.gitlab.com/downloads/" rel="nofollow noreferrer">here</a>. I wanted to use it to manage my Git repo better and more visually and this seemed to be a good choice. But now I run into issues getting it to work.</p>
  
  <p>Just to make it really work and update all files I decided to rerun the configuration using <code>gitlab-ctl reconfigure</code>. Second run did work:</p>
  
  <pre><code>Chef Client finished, 4 resources updated
  gitlab Reconfigured!
  </code></pre>
  
  <p>See <a href="http://pastebin.com/cE7DYv6w" rel="nofollow noreferrer">full log</a></p>
  
  <p>The hoster had already put NGINX on 8080 not get into an argument with Apache running on port 80 where we have a LAMP project running.  But now Ruby's Unicorn Web Server seems to be conflicting with NGINX. I have worked with NGINX a little bit, not much and this is my first stab at Gitlab. Anyways this is what I figured out with the help of my hoster.</p>
  
  <p>When I log into testserver.domain.net and pass the following command:</p>
  
  <p><code>netstat -ln |grep 8080</code> I see</p>
  
  <pre><code>tcp        0      0 127.0.0.1:8080              0.0.0.0:*                   LISTEN      
  </code></pre>
  
  <p>So something is running on 8080
  According to my hoster it should run on 0.0.0.0:8080. And when we check what is running on that port we see</p>
  
  <pre><code>netstat -tupln |grep 8080
  tcp        0      0 127.0.0.1:8080              0.0.0.0:*                   LISTEN      21627/unicorn maste 
  </code></pre>
  
  <p>When we check the process id 21627, we see</p>
  
  <pre><code>cat /proc/21627/cmdline 
  unicorn master -E production -c /var/opt/gitlab/gitlab-rails/etc/unicorn.rb /opt/gitlab/embedded/service/gitlab-rails/config.ru
  </code></pre>
  
  <p>That is a Ruby process, and not a NGINX process.</p>
  
  <p>So NGINX seems to be conflicting with Unicorn.</p>
  
  <p>And when we check the logs of nginx we see that nginx cannot get going because of this:</p>
  
  <pre><code>tail -f /var/log/gitlab/nginx/error.log 
  2014/07/28 09:43:10 [emerg] 23122#0: bind() to 0.0.0.0:8080 failed (98: Address already in use)
  2014/07/28 09:43:10 [emerg] 23122#0: still could not bind()
  2014/07/28 09:43:12 [emerg] 23123#0: bind() to 0.0.0.0:8080 failed (98: Address already in use)
  2014/07/28 09:43:12 [emerg] 23123#0: bind() to 0.0.0.0:8080 failed (98: Address already in use)
  2014/07/28 09:43:12 [emerg] 23123#0: bind() to 0.0.0.0:8080 failed (98: Address already in use)
  2014/07/28 09:43:12 [emerg] 23123#0: bind() to 0.0.0.0:8080 failed (98: Address already in use)
  2014/07/28 09:43:12 [emerg] 23123#0: bind() to 0.0.0.0:8080 failed (98: Address already in use)
  2014/07/28 09:43:12 [emerg] 23123#0: still could not bind()
  </code></pre>
  
  <p>I googled Unicorn.rb and found this <a href="https://github.com/blog/517-unicorn" rel="nofollow noreferrer">link</a>. I also read that:</p>
  
  <blockquote>
    <p>Unicorn is an HTTP server for Rack applications designed to only serve
    fast clients on low-latency, high-bandwidth connections and take
    advantage of features in Unix/Unix-like kernels. Slow clients should
    only be served by placing a reverse proxy capable of fully buffering
    both the the request and response in between Unicorn and slow clients.</p>
  </blockquote>
  
  <p>When I check the file <code>/var/opt/gitlab/gitlab-rails/etc/unicorn.rb</code> I do see it uses 8080. Issue is that it seems Unicorn should work together with NGINX so perhaps I should not change the port. </p>
  
  <p>What step should I take to make Gitlab work? Can Gitlab work without Unicorn? I would think not.  Should I then pick another port for it or perhaps for NGINX?</p>