title: Running docker-compose up with Python's 'fabric'
body: <p>I am using Docker (+ Docker Compose). All <code>docker-compose</code> interaction occurs via the Python '<a href="http://www.fabfile.org/" rel="nofollow noreferrer">fabric</a>' package (v1).</p>
  
  <p>Example:</p>
  
  <pre><code>def runserver():
      local('docker-compose up')
  </code></pre>
  
  <p>and:</p>
  
  <pre><code>$ fab runserver
  </code></pre>
  
  <p>Everything behaves normally until I attempt to <code>^C</code> out of a running <code>docker-compose up</code>:</p>
  
  <ol>
  <li><code>docker-compose</code> appears to receive the <code>^C</code> (<code>SIGINT</code>?) signal as it starts stopping my containers - e.g.:</li>
  </ol>
  
  <pre><code>Stopping celery-export ... done
  Stopping celery        ...
  </code></pre>
  
  <p>However during the container stopping process (sometimes as long as 10 seconds if a container doesn't respond to signals properly), I can press enter / return and see / interact with my shell (as if the process has ended).</p>
  
  <p>Though at this stage the containers haven't finished stopping yet (there's not a <code>done</code> next to each <code>Stopping ...</code> line). It's as if I've prematurely been given access to my shell, which I can freely use. If a late-finishing container eventually stops (usually after 10 seconds), it'll draw the <code>done</code> line over what I'm currently doing in my terminal.</p>
  
  <p>Example:</p>
  
  <pre><code>Stopping celery-export ... done
  Stopping celery        ...
  Stopping redis         ...
  
  $ uptime 
  10:54  up 1 day, 17:22, 2 users, load averages: 1.73 1.94 1.92
  Stopping celery        ... done
  Stopping redis         ... done
  </code></pre>
  
  <p>This does not occur when I call <code>docker-compose up</code> directly (outside of fabric) so I suspect that it's something to do with fabric wrapping the execution of the command.</p>
  
  <p>The expected behaviour being that I cannot access my shell until after the container stopping process finishes. </p>
  
  <p>Forgive my lack of proper terminology for describing this issue, and if this'd be more appropriate on Superuser instead of SO.</p>