Compose: Cannot do interactive debugging

[rightaway]

I have launched a Django web application from within fig and commonly use import ipdb; ipdb.set_trace() (or the more common pdb instead of ipdb) which is a common way of debugging apps. What's supposed to happen is when the code hits that part an interactive debugger appears on the console where the app has been running allowing you to type commands to see the state of the application.

When it's run from fig though, it appears on the console but since you can't type anything in it the debugging app quits with an error. Here's what happens on the console.

web_1     | > /something.py(126)method()
web_1     |     127 
web_1     | --> 128     line_to_debug()
web_1     |     129       # More code...
web_1     | 
web_1     | ipdb> 
web_1     |
web_1     |  ... back to application output since nothing could be entered at ipdb> prompt above ...

There should be a way to allow for interactive debugging which is a very common use case in development. Something like specifying that one of the services in the fig configuration can accept input.

[aanand]

The ideal solution to this would be to run your web service with fig run web, so it's interactive. However, we need #251 to be cleaned up and merged first, so that fig run exposes ports.

[alf]

One way to do this is to add net: "host" in your fig.yaml and then use fig run. This does not work if you link with other containers however. Hopefully #251 gets some love soon.

[artofhuman]

:+1:

[thaJeztah]

Be very careful when using net: "host", there's a warning in the documentation as well;

Note: This gives the container full access to local system services such as D-bus and is therefore considered insecure.

I cannot find the issue this was mentioned in, but if I recall correctly; When running 'host' as network-mode, doing sudo restart -h now _inside_ a container will actually restart the _host_ as well.

(If someone has more info on this, feel free to add)

[jcalazan]

+1 just saw the same issue today

[andrewmichaelsmith]

+1 also experiencing this issue

What I see is:

app_1 |   File "/usr/lib/python2.7/bdb.py", line 68, in dispatch_line
app_1 |     if self.quitting: raise BdbQuit
app_1 | bdb.BdbQuit
app_app_1 exited with code 1

[ir4y]

+1

[gone]

+1

[naps62]

+1

[andres-root]

+1

[baptistedonaux]

+1

[foliea]

+1 same with pry-rails.

[aidanlister]

+1

[deniszgonjanin]

+1

[aanand]

Now that #485 is merged, this should be possible with fig run --service-ports web.

[aidanlister]

So how does this work?

I do a "fig run --service-ports web" which gives me an interactive TTY to debug "web" on, but what about the other containers? Do I launch them first e.g. fig run db; fig run redis; fig run worker; then "fig run --service-ports web"? That doesn't seem like it would link the containers together ...

[aanand]

@aidanlister if the web service depends on any other services, fig run will start them first if they're not already running, and link the web container to them.

[kevinpostal]

one workaround till this is fixed is to use epdb

https://bitbucket.org/dugan/epdb/wiki/Home

[aidanlister]

Ah I see, so in the next fig release "fig run --service-ports web" should give me a TTY to debug web on? Can you explain what the TTY has to do with the service ports just so I understand? Sorry!

[aanand]

@aidanlister fig up runs multiple services with ports exposed but non-interactively; fig run runs a single service interactively but without ports exposed by default. --service-ports overrides that default so that it's running _both_ interactively _and_ with ports exposed, meaning you can run your web app with the debugger turned on.

[aidanlister]

Ah I see, thank you!

[aanand]

--service-ports is supported in the Docker Compose 1.1 release candidate.