title: Why does uWSGI fail to start in Docker?
body: <p>I am relatively new to using uWSGI to serve Python applications and I am attempting to start a uWSGI process in emperor mode with a vassal, but every time I try to start uWSGI inside of Docker with the following command (as <code>root</code>):</p>
  
  <pre><code># /usr/local/bin/uwsgi --ini /etc/uwsgi/emperor.ini
  </code></pre>
  
  <p>What I get as a response is:</p>
  
  <pre><code>[uWSGI] getting INI configuration from /etc/uwsgi/emperor.ini
  2.0.13.1
  </code></pre>
  
  <p>The <code>emperor.ini</code> configuration file looks like:</p>
  
  <pre><code># files/etc/uwsgi/emperor.ini
  [uwsgi]
  emperor = /etc/uwsgi/apps-enabled
  die-on-term = true
  log-date = true
  </code></pre>
  
  <p>While the only vassal's configuration looks like:</p>
  
  <pre><code># files/etc/uwsgi/apps-enabled/application.ini
  [uwsgi]
  app_dir = /var/www/server
  plugin = python
  master = true
  callable = app
  chdir = %(app_dir)
  mount = /=%(app_dir)/start.py
  protocol = uwsgi
  socket = :8079
  uid = www-data
  gid = www-data
  
  buffer-size = 32768
  enable-threads = true
  single-interpreter = true
  processes = 1
  
  stats = 127.0.0.1:1717
  </code></pre>
  
  <p>(<strong>NB:</strong> The filenames above are given in terms of where they live relative to the Dockerfile which will then copy them to the correct locations, basically removing the prefix <code>files</code>)</p>
  
  <p>Currently the uWSGI Docker image I'm using is built off of an <code>ubuntu:trusty</code> base image (though I've tried <code>ubuntu:latest</code> and <code>alpine:latest</code> and encountered the same problem), and although I am attempting to launch the uWSGI process with supervisor, as stated previously, it also fails when run directly from the command line. In the Docker image I'm installing uWSGI using <code>pip</code> but have also tried using <code>apt-get</code> with the same result.</p>
  
  <p>I should also mention that I've tried different versions of uWSGI 2.0.13.1 and 1.9.something with the same result, if that helps.</p>
  
  <pre><code># Dockerfile
  FROM ubuntu:trusty
  MAINTAINER Sean Quinn "me@mail.com"
  
  RUN apt-get update \
   &amp;&amp; apt-get install -y \
        ack-grep git nano \
        supervisor \
        build-essential gcc python python-dev python-pip
  
  RUN sed -i 's/^\(\[supervisord\]\)$/\1\nnodaemon=true/' /etc/supervisor/supervisord.conf \
   &amp;&amp; sed -i 's/^\(\[supervisord\]\)$/\1\nloglevel=debug/' /etc/supervisor/supervisord.conf \
   &amp;&amp; sed -i 's/^\(files = .*\)$/;\1/' /etc/supervisor/supervisord.conf \
   &amp;&amp; sed -i 's/^\(\[include\]\)$/\1\nfiles = \/etc\/supervisor\/conf.d\/*.conf/' /etc/supervisor/supervisord.conf
  
  ENV UWSGI_VERSION 2.0.13.1
  
  RUN pip install uwsgi==${UWSGI_VERSION}
  
  RUN mkdir -p /etc/uwsgi \
   &amp;&amp; mkdir -p /etc/uwsgi/apps-available \
   &amp;&amp; mkdir -p /etc/uwsgi/apps-enabled \
   &amp;&amp; mkdir -p /var/log/uwsgi
  
  COPY files/etc/supervisor/conf.d/uwsgi.conf /etc/supervisor/conf.d/uwsgi.conf
  COPY files/etc/uwsgi/emperor.ini /etc/uwsgi/emperor.ini
  
  VOLUME /etc/uwsgi/apps-enabled
  VOLUME /var/www
  
  ENTRYPOINT ["/usr/bin/supervisord"]
  CMD ["-c", "/etc/supervisor/supervisord.conf"]
  </code></pre>
  
  <p>As mentioned, the <code>supervisord</code> process attempts to launch the uWSGI process using the following supervisor configuration.</p>
  
  <pre><code># files/etc/supervisor/conf.d/uwsgi.conf
  [program:uwsgi]
  command=/usr/local/bin/uwsgi --ini /etc/uwsgi/emperor.ini
  user=root
  </code></pre>
  
  <p>The application Python files are mounted in a subdirectory of <code>/var/www</code> and the application uWSGI configuration is mounted into <code>/etc/uwsgi/apps-enabled</code>.</p>
  
  <p>The bizarre thing is, if I install supervisor and uWSGI on a new Ubuntu VM (outside of Docker) with all of the configuration and files in place I can see uWSGI properly process the <code>emperor.ini</code> and read the vassal <code>.ini</code> files. I haven't yet attempted to add nginx into the equation because I want to make sure uWSGI is starting and reading configuration files correctly first and foremost.</p>
  
  <p>Is there any way to increase the logging or ascertain why I'm only seeing what appears to be the version number of the uWSGI binary? It's like the uWSGI process is completely ignoring command line options. I feel like I'm missing something that should be obvious.</p>
  
  <p>Thanks in advance for any help anyone can give!</p>