# Nameko eventlet Back Door

**URL:** <https://discourse.nameko.io/t/nameko-eventlet-back-door/184>\
**Category:** googlegroup\
**Created:** [April 5, 2017, 9:22am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184 "2017-04-05T09:22:06Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![simon\_harrison](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@simon\_harrison](https://discourse.nameko.io/u/simon_harrison)\
**Post date:** [April 5, 2017, 9:22am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/1 "2017-04-05T09:22:06Z")

</div>

Hi devs

We''re experiencing hanging services in production. Previously I've used  
the eventlet backdoor to telnet in and inspect what workers are in flight  
and what they are executing, but I cannot remember the steps to do this and  
it doesn't seem to be documented - at least not outside of the nameko test  
suite.

Can you take us through the steps to do this please? starting from defining  
the port in our config, telnetting in and then inspecting the live objects  
to find what workers are executing what and with what call args? We're  
using the HTTP entrypoints if that is important.

Thanks

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [April 5, 2017, 9:26am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/2 "2017-04-05T09:26:57Z")

</div>

Are you running your services with `nameko run`?

nameko run --help  
usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class] ...]

Run nameko services. Given a python path to a module containing one or more  
nameko services, will host and run them. By default this will try to find  
classes that look like services (anything with nameko entrypoints), but a  
specific service can be specified via ``nameko run module:ServiceClass``.

positional arguments:  
&nbsp;&nbsp;module[:service class]  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes to run

optional arguments:  
&nbsp;&nbsp;-h, --help show this help message and exit  
&nbsp;&nbsp;--config CONFIG The YAML configuration file  
&nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
\* --backdoor-port BACKDOOR\_PORT\*  
\* Specify a port number to host a backdoor, which  
can be\*  
\* connected to for an interactive interpreter within  
the\*  
\* running service process using `nameko backdoor`.\*

if not, have a look at the source for the same

Best,  
David

> **···**
>
> On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> 
> > Hi devs
> > 
> > We''re experiencing hanging services in production. Previously I've used  
> > the eventlet backdoor to telnet in and inspect what workers are in flight  
> > and what they are executing, but I cannot remember the steps to do this and  
> > it doesn't seem to be documented - at least not outside of the nameko test  
> > suite.
> > 
> > Can you take us through the steps to do this please? starting from  
> > defining the port in our config, telnetting in and then inspecting the live  
> > objects to find what workers are executing what and with what call args?  
> > We're using the HTTP entrypoints if that is important.
> > 
> > Thanks

---

<div class="post-metadata">

**Author:** ![simon\_harrison](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@simon\_harrison](https://discourse.nameko.io/u/simon_harrison)\
**Post date:** [April 5, 2017, 10:08am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/3 "2017-04-05T10:08:39Z")

</div>

Hi David

Yes we are, and we are now specifying a backdoor port.

> **···**
>
> On Wednesday, 5 April 2017 10:26:57 UTC+1, David Szotten wrote:
> 
> > Are you running your services with `nameko run`?
> > 
> > nameko run --help  
> > usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class] ...]
> > 
> > Run nameko services. Given a python path to a module containing one or more  
> > nameko services, will host and run them. By default this will try to find  
> > classes that look like services (anything with nameko entrypoints), but a  
> > specific service can be specified via ``nameko run module:ServiceClass``.
> > 
> > positional arguments:  
> > &nbsp;&nbsp;module[:service class]  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes to run
> > 
> > optional arguments:  
> > &nbsp;&nbsp;-h, --help show this help message and exit  
> > &nbsp;&nbsp;--config CONFIG The YAML configuration file  
> > &nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
> > \* --backdoor-port BACKDOOR\_PORT\*  
> > \* Specify a port number to host a backdoor, which  
> > can be\*  
> > \* connected to for an interactive interpreter  
> > within the\*  
> > \* running service process using `nameko backdoor`.\*
> > 
> > if not, have a look at the source for the same
> > 
> > Best,  
> > David
> > 
> > On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> > 
> > > Hi devs
> > > 
> > > We''re experiencing hanging services in production. Previously I've used  
> > > the eventlet backdoor to telnet in and inspect what workers are in flight  
> > > and what they are executing, but I cannot remember the steps to do this and  
> > > it doesn't seem to be documented - at least not outside of the nameko test  
> > > suite.
> > > 
> > > Can you take us through the steps to do this please? starting from  
> > > defining the port in our config, telnetting in and then inspecting the live  
> > > objects to find what workers are executing what and with what call args?  
> > > We're using the HTTP entrypoints if that is important.
> > > 
> > > Thanks

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [April 5, 2017, 10:10am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/4 "2017-04-05T10:10:21Z")

</div>

Hi,

I'm afraid i can't tell if your problem is solved or if you are looking for  
additional info/advice?

Best,  
David

> **···**
>
> On Wednesday, 5 April 2017 11:08:39 UTC+1, simon harrison wrote:
> 
> > Hi David
> > 
> > Yes we are, and we are now specifying a backdoor port.
> > 
> > On Wednesday, 5 April 2017 10:26:57 UTC+1, David Szotten wrote:
> > 
> > > Are you running your services with `nameko run`?
> > > 
> > > nameko run --help  
> > > usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class] ...]
> > > 
> > > Run nameko services. Given a python path to a module containing one or  
> > > more  
> > > nameko services, will host and run them. By default this will try to find  
> > > classes that look like services (anything with nameko entrypoints), but a  
> > > specific service can be specified via ``nameko run module:ServiceClass``.
> > > 
> > > positional arguments:  
> > > &nbsp;&nbsp;module[:service class]  
> > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes to run
> > > 
> > > optional arguments:  
> > > &nbsp;&nbsp;-h, --help show this help message and exit  
> > > &nbsp;&nbsp;--config CONFIG The YAML configuration file  
> > > &nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
> > > \* --backdoor-port BACKDOOR\_PORT\*  
> > > \* Specify a port number to host a backdoor, which  
> > > can be\*  
> > > \* connected to for an interactive interpreter  
> > > within the\*  
> > > \* running service process using `nameko backdoor`.\*
> > > 
> > > if not, have a look at the source for the same
> > > 
> > > Best,  
> > > David
> > > 
> > > On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> > > 
> > > > Hi devs
> > > > 
> > > > We''re experiencing hanging services in production. Previously I've used  
> > > > the eventlet backdoor to telnet in and inspect what workers are in flight  
> > > > and what they are executing, but I cannot remember the steps to do this and  
> > > > it doesn't seem to be documented - at least not outside of the nameko test  
> > > > suite.
> > > > 
> > > > Can you take us through the steps to do this please? starting from  
> > > > defining the port in our config, telnetting in and then inspecting the live  
> > > > objects to find what workers are executing what and with what call args?  
> > > > We're using the HTTP entrypoints if that is important.
> > > > 
> > > > Thanks

---

<div class="post-metadata">

**Author:** ![simon\_harrison](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@simon\_harrison](https://discourse.nameko.io/u/simon_harrison)\
**Post date:** [April 5, 2017, 10:46am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/5 "2017-04-05T10:46:37Z")

</div>

What's the trick to get the python interpreter to behave?

``apt-get install libreadline`` doesn't help.

Then we need to find the workers from the runner object.

> **···**
>
> On Wednesday, 5 April 2017 11:10:21 UTC+1, David Szotten wrote:
> 
> > Hi,
> > 
> > I'm afraid i can't tell if your problem is solved or if you are looking  
> > for additional info/advice?
> > 
> > Best,  
> > David
> > 
> > On Wednesday, 5 April 2017 11:08:39 UTC+1, simon harrison wrote:
> > 
> > > Hi David
> > > 
> > > Yes we are, and we are now specifying a backdoor port.
> > > 
> > > On Wednesday, 5 April 2017 10:26:57 UTC+1, David Szotten wrote:
> > > 
> > > > Are you running your services with `nameko run`?
> > > > 
> > > > nameko run --help  
> > > > usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class] ...]
> > > > 
> > > > Run nameko services. Given a python path to a module containing one or  
> > > > more  
> > > > nameko services, will host and run them. By default this will try to find  
> > > > classes that look like services (anything with nameko entrypoints), but a  
> > > > specific service can be specified via ``nameko run module:ServiceClass``.
> > > > 
> > > > positional arguments:  
> > > > &nbsp;&nbsp;module[:service class]  
> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes to run
> > > > 
> > > > optional arguments:  
> > > > &nbsp;&nbsp;-h, --help show this help message and exit  
> > > > &nbsp;&nbsp;--config CONFIG The YAML configuration file  
> > > > &nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
> > > > \* --backdoor-port BACKDOOR\_PORT\*  
> > > > \* Specify a port number to host a backdoor, which  
> > > > can be\*  
> > > > \* connected to for an interactive interpreter  
> > > > within the\*  
> > > > \* running service process using `nameko  
> > > > backdoor`.\*
> > > > 
> > > > if not, have a look at the source for the same
> > > > 
> > > > Best,  
> > > > David
> > > > 
> > > > On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> > > > 
> > > > > Hi devs
> > > > > 
> > > > > We''re experiencing hanging services in production. Previously I've  
> > > > > used the eventlet backdoor to telnet in and inspect what workers are in  
> > > > > flight and what they are executing, but I cannot remember the steps to do  
> > > > > this and it doesn't seem to be documented - at least not outside of the  
> > > > > nameko test suite.
> > > > > 
> > > > > Can you take us through the steps to do this please? starting from  
> > > > > defining the port in our config, telnetting in and then inspecting the live  
> > > > > objects to find what workers are executing what and with what call args?  
> > > > > We're using the HTTP entrypoints if that is important.
> > > > > 
> > > > > Thanks

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [April 5, 2017, 10:48am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/6 "2017-04-05T10:48:55Z")

</div>

the runner should be available (injected into  
locals): [https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106](https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106)

you're a bit limited since going via telnet/netcat, but rlwrap helps a bit

d

> **···**
>
> On Wednesday, 5 April 2017 11:46:37 UTC+1, simon harrison wrote:
> 
> > What's the trick to get the python interpreter to behave?
> > 
> > ``apt-get install libreadline`` doesn't help.
> > 
> > Then we need to find the workers from the runner object.
> > 
> > On Wednesday, 5 April 2017 11:10:21 UTC+1, David Szotten wrote:
> > 
> > > Hi,
> > > 
> > > I'm afraid i can't tell if your problem is solved or if you are looking  
> > > for additional info/advice?
> > > 
> > > Best,  
> > > David
> > > 
> > > On Wednesday, 5 April 2017 11:08:39 UTC+1, simon harrison wrote:
> > > 
> > > > Hi David
> > > > 
> > > > Yes we are, and we are now specifying a backdoor port.
> > > > 
> > > > On Wednesday, 5 April 2017 10:26:57 UTC+1, David Szotten wrote:
> > > > 
> > > > > Are you running your services with `nameko run`?
> > > > > 
> > > > > nameko run --help  
> > > > > usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class] ...]
> > > > > 
> > > > > Run nameko services. Given a python path to a module containing one or  
> > > > > more  
> > > > > nameko services, will host and run them. By default this will try to  
> > > > > find  
> > > > > classes that look like services (anything with nameko entrypoints), but  
> > > > > a  
> > > > > specific service can be specified via ``nameko run  
> > > > > module:ServiceClass``.
> > > > > 
> > > > > positional arguments:  
> > > > > &nbsp;&nbsp;module[:service class]  
> > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes to  
> > > > > run
> > > > > 
> > > > > optional arguments:  
> > > > > &nbsp;&nbsp;-h, --help show this help message and exit  
> > > > > &nbsp;&nbsp;--config CONFIG The YAML configuration file  
> > > > > &nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
> > > > > \* --backdoor-port BACKDOOR\_PORT\*  
> > > > > \* Specify a port number to host a backdoor,  
> > > > > which can be\*  
> > > > > \* connected to for an interactive interpreter  
> > > > > within the\*  
> > > > > \* running service process using `nameko  
> > > > > backdoor`.\*
> > > > > 
> > > > > if not, have a look at the source for the same
> > > > > 
> > > > > Best,  
> > > > > David
> > > > > 
> > > > > On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> > > > > 
> > > > > > Hi devs
> > > > > > 
> > > > > > We''re experiencing hanging services in production. Previously I've  
> > > > > > used the eventlet backdoor to telnet in and inspect what workers are in  
> > > > > > flight and what they are executing, but I cannot remember the steps to do  
> > > > > > this and it doesn't seem to be documented - at least not outside of the  
> > > > > > nameko test suite.
> > > > > > 
> > > > > > Can you take us through the steps to do this please? starting from  
> > > > > > defining the port in our config, telnetting in and then inspecting the live  
> > > > > > objects to find what workers are executing what and with what call args?  
> > > > > > We're using the HTTP entrypoints if that is important.
> > > > > > 
> > > > > > Thanks

---

<div class="post-metadata">

**Author:** ![simon\_harrison](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@simon\_harrison](https://discourse.nameko.io/u/simon_harrison)\
**Post date:** [April 5, 2017, 11:04am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/7 "2017-04-05T11:04:24Z")

</div>

Cool. Making progress. Thanks for the help here.

We can get the container and then see ``\_worker\_threads``.

How can we see what entrypoint is being worked on by a worker? Is that even  
possible? Because that's what we're after here.

Thanks again!

> **···**
>
> On Wednesday, 5 April 2017 11:48:55 UTC+1, David Szotten wrote:
> 
> > the runner should be available (injected into locals):  
> > [https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106](https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106)
> > 
> > you're a bit limited since going via telnet/netcat, but rlwrap helps a bit
> > 
> > d
> > 
> > On Wednesday, 5 April 2017 11:46:37 UTC+1, simon harrison wrote:
> > 
> > > What's the trick to get the python interpreter to behave?
> > > 
> > > ``apt-get install libreadline`` doesn't help.
> > > 
> > > Then we need to find the workers from the runner object.
> > > 
> > > On Wednesday, 5 April 2017 11:10:21 UTC+1, David Szotten wrote:
> > > 
> > > > Hi,
> > > > 
> > > > I'm afraid i can't tell if your problem is solved or if you are looking  
> > > > for additional info/advice?
> > > > 
> > > > Best,  
> > > > David
> > > > 
> > > > On Wednesday, 5 April 2017 11:08:39 UTC+1, simon harrison wrote:
> > > > 
> > > > > Hi David
> > > > > 
> > > > > Yes we are, and we are now specifying a backdoor port.
> > > > > 
> > > > > On Wednesday, 5 April 2017 10:26:57 UTC+1, David Szotten wrote:
> > > > > 
> > > > > > Are you running your services with `nameko run`?
> > > > > > 
> > > > > > nameko run --help  
> > > > > > usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class] ...]
> > > > > > 
> > > > > > Run nameko services. Given a python path to a module containing one or  
> > > > > > more  
> > > > > > nameko services, will host and run them. By default this will try to  
> > > > > > find  
> > > > > > classes that look like services (anything with nameko entrypoints),  
> > > > > > but a  
> > > > > > specific service can be specified via ``nameko run  
> > > > > > module:ServiceClass``.
> > > > > > 
> > > > > > positional arguments:  
> > > > > > &nbsp;&nbsp;module[:service class]  
> > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes to  
> > > > > > run
> > > > > > 
> > > > > > optional arguments:  
> > > > > > &nbsp;&nbsp;-h, --help show this help message and exit  
> > > > > > &nbsp;&nbsp;--config CONFIG The YAML configuration file  
> > > > > > &nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
> > > > > > \* --backdoor-port BACKDOOR\_PORT\*  
> > > > > > \* Specify a port number to host a backdoor,  
> > > > > > which can be\*  
> > > > > > \* connected to for an interactive interpreter  
> > > > > > within the\*  
> > > > > > \* running service process using `nameko  
> > > > > > backdoor`.\*
> > > > > > 
> > > > > > if not, have a look at the source for the same
> > > > > > 
> > > > > > Best,  
> > > > > > David
> > > > > > 
> > > > > > On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> > > > > > 
> > > > > > > Hi devs
> > > > > > > 
> > > > > > > We''re experiencing hanging services in production. Previously I've  
> > > > > > > used the eventlet backdoor to telnet in and inspect what workers are in  
> > > > > > > flight and what they are executing, but I cannot remember the steps to do  
> > > > > > > this and it doesn't seem to be documented - at least not outside of the  
> > > > > > > nameko test suite.
> > > > > > > 
> > > > > > > Can you take us through the steps to do this please? starting from  
> > > > > > > defining the port in our config, telnetting in and then inspecting the live  
> > > > > > > objects to find what workers are executing what and with what call args?  
> > > > > > > We're using the HTTP entrypoints if that is important.
> > > > > > > 
> > > > > > > Thanks

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [April 5, 2017, 11:18am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/8 "2017-04-05T11:18:38Z")

</div>

\_worker\_threads is a dict of greenthreads keyed by the worker context for  
each call. Inspecting the worker context will tell you everything about  
that worker -- the entrypoint that fired, its arguments, context data etc.

Another tip is that you can inspect the greenthread itself to see what it's  
currently doing. This is useful if your workers are hanging. Example:

ct = list(runner.containers)[0] # first container  
gt = list(ct.\_worker\_threads.values())[0] # first worker greenthread

import traceback  
traceback.print\_stack(gt.gr\_frame) # print current stack

You will find the thread sitting waiting for some I/O (it has to be in  
order for your thread to be running). If the worker is hung it'll be the  
same stack every time you check.

> **···**
>
> On Wednesday, April 5, 2017 at 12:04:24 PM UTC+1, simon harrison wrote:
> 
> > Cool. Making progress. Thanks for the help here.
> > 
> > We can get the container and then see ``\_worker\_threads``.
> > 
> > How can we see what entrypoint is being worked on by a worker? Is that  
> > even possible? Because that's what we're after here.
> > 
> > Thanks again!
> > 
> > On Wednesday, 5 April 2017 11:48:55 UTC+1, David Szotten wrote:
> > 
> > > the runner should be available (injected into locals):  
> > > [https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106](https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106)
> > > 
> > > you're a bit limited since going via telnet/netcat, but rlwrap helps a bit
> > > 
> > > d
> > > 
> > > On Wednesday, 5 April 2017 11:46:37 UTC+1, simon harrison wrote:
> > > 
> > > > What's the trick to get the python interpreter to behave?
> > > > 
> > > > ``apt-get install libreadline`` doesn't help.
> > > > 
> > > > Then we need to find the workers from the runner object.
> > > > 
> > > > On Wednesday, 5 April 2017 11:10:21 UTC+1, David Szotten wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > I'm afraid i can't tell if your problem is solved or if you are looking  
> > > > > for additional info/advice?
> > > > > 
> > > > > Best,  
> > > > > David
> > > > > 
> > > > > On Wednesday, 5 April 2017 11:08:39 UTC+1, simon harrison wrote:
> > > > > 
> > > > > > Hi David
> > > > > > 
> > > > > > Yes we are, and we are now specifying a backdoor port.
> > > > > > 
> > > > > > On Wednesday, 5 April 2017 10:26:57 UTC+1, David Szotten wrote:
> > > > > > 
> > > > > > > Are you running your services with `nameko run`?
> > > > > > > 
> > > > > > > nameko run --help  
> > > > > > > usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class] ...]
> > > > > > > 
> > > > > > > Run nameko services. Given a python path to a module containing one  
> > > > > > > or more  
> > > > > > > nameko services, will host and run them. By default this will try to  
> > > > > > > find  
> > > > > > > classes that look like services (anything with nameko entrypoints),  
> > > > > > > but a  
> > > > > > > specific service can be specified via ``nameko run  
> > > > > > > module:ServiceClass``.
> > > > > > > 
> > > > > > > positional arguments:  
> > > > > > > &nbsp;&nbsp;module[:service class]  
> > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes to  
> > > > > > > run
> > > > > > > 
> > > > > > > optional arguments:  
> > > > > > > &nbsp;&nbsp;-h, --help show this help message and exit  
> > > > > > > &nbsp;&nbsp;--config CONFIG The YAML configuration file  
> > > > > > > &nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
> > > > > > > \* --backdoor-port BACKDOOR\_PORT\*  
> > > > > > > \* Specify a port number to host a backdoor,  
> > > > > > > which can be\*  
> > > > > > > \* connected to for an interactive interpreter  
> > > > > > > within the\*  
> > > > > > > \* running service process using `nameko  
> > > > > > > backdoor`.\*
> > > > > > > 
> > > > > > > if not, have a look at the source for the same
> > > > > > > 
> > > > > > > Best,  
> > > > > > > David
> > > > > > > 
> > > > > > > On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> > > > > > > 
> > > > > > > > Hi devs
> > > > > > > > 
> > > > > > > > We''re experiencing hanging services in production. Previously I've  
> > > > > > > > used the eventlet backdoor to telnet in and inspect what workers are in  
> > > > > > > > flight and what they are executing, but I cannot remember the steps to do  
> > > > > > > > this and it doesn't seem to be documented - at least not outside of the  
> > > > > > > > nameko test suite.
> > > > > > > > 
> > > > > > > > Can you take us through the steps to do this please? starting from  
> > > > > > > > defining the port in our config, telnetting in and then inspecting the live  
> > > > > > > > objects to find what workers are executing what and with what call args?  
> > > > > > > > We're using the HTTP entrypoints if that is important.
> > > > > > > > 
> > > > > > > > Thanks

---

<div class="post-metadata">

**Author:** ![simon\_harrison](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@simon\_harrison](https://discourse.nameko.io/u/simon_harrison)\
**Post date:** [April 5, 2017, 11:54am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/9 "2017-04-05T11:54:47Z")

</div>

perfect! thanks chaps.

this sort of debugging know-how could find themselves a place in the docs?  
how would you feel about a Troubleshooting section?

> **···**
>
> On Wednesday, 5 April 2017 12:18:38 UTC+1, Matt Yule-Bennett wrote:
> 
> > \_worker\_threads is a dict of greenthreads keyed by the worker context for  
> > each call. Inspecting the worker context will tell you everything about  
> > that worker -- the entrypoint that fired, its arguments, context data etc.
> > 
> > Another tip is that you can inspect the greenthread itself to see what  
> > it's currently doing. This is useful if your workers are hanging. Example:
> > 
> > ct = list(runner.containers)[0] # first container  
> > gt = list(ct.\_worker\_threads.values())[0] # first worker greenthread
> > 
> > import traceback  
> > traceback.print\_stack(gt.gr\_frame) # print current stack
> > 
> > You will find the thread sitting waiting for some I/O (it has to be in  
> > order for your thread to be running). If the worker is hung it'll be the  
> > same stack every time you check.
> > 
> > On Wednesday, April 5, 2017 at 12:04:24 PM UTC+1, simon harrison wrote:
> > 
> > > Cool. Making progress. Thanks for the help here.
> > > 
> > > We can get the container and then see ``\_worker\_threads``.
> > > 
> > > How can we see what entrypoint is being worked on by a worker? Is that  
> > > even possible? Because that's what we're after here.
> > > 
> > > Thanks again!
> > > 
> > > On Wednesday, 5 April 2017 11:48:55 UTC+1, David Szotten wrote:
> > > 
> > > > the runner should be available (injected into locals):  
> > > > [https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106](https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106)
> > > > 
> > > > you're a bit limited since going via telnet/netcat, but rlwrap helps a  
> > > > bit
> > > > 
> > > > d
> > > > 
> > > > On Wednesday, 5 April 2017 11:46:37 UTC+1, simon harrison wrote:
> > > > 
> > > > > What's the trick to get the python interpreter to behave?
> > > > > 
> > > > > ``apt-get install libreadline`` doesn't help.
> > > > > 
> > > > > Then we need to find the workers from the runner object.
> > > > > 
> > > > > On Wednesday, 5 April 2017 11:10:21 UTC+1, David Szotten wrote:
> > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I'm afraid i can't tell if your problem is solved or if you are  
> > > > > > looking for additional info/advice?
> > > > > > 
> > > > > > Best,  
> > > > > > David
> > > > > > 
> > > > > > On Wednesday, 5 April 2017 11:08:39 UTC+1, simon harrison wrote:
> > > > > > 
> > > > > > > Hi David
> > > > > > > 
> > > > > > > Yes we are, and we are now specifying a backdoor port.
> > > > > > > 
> > > > > > > On Wednesday, 5 April 2017 10:26:57 UTC+1, David Szotten wrote:
> > > > > > > 
> > > > > > > > Are you running your services with `nameko run`?
> > > > > > > > 
> > > > > > > > nameko run --help  
> > > > > > > > usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class] ...]
> > > > > > > > 
> > > > > > > > Run nameko services. Given a python path to a module containing one  
> > > > > > > > or more  
> > > > > > > > nameko services, will host and run them. By default this will try to  
> > > > > > > > find  
> > > > > > > > classes that look like services (anything with nameko entrypoints),  
> > > > > > > > but a  
> > > > > > > > specific service can be specified via ``nameko run  
> > > > > > > > module:ServiceClass``.
> > > > > > > > 
> > > > > > > > positional arguments:  
> > > > > > > > &nbsp;&nbsp;module[:service class]  
> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes  
> > > > > > > > to run
> > > > > > > > 
> > > > > > > > optional arguments:  
> > > > > > > > &nbsp;&nbsp;-h, --help show this help message and exit  
> > > > > > > > &nbsp;&nbsp;--config CONFIG The YAML configuration file  
> > > > > > > > &nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
> > > > > > > > \* --backdoor-port BACKDOOR\_PORT\*  
> > > > > > > > \* Specify a port number to host a backdoor,  
> > > > > > > > which can be\*  
> > > > > > > > \* connected to for an interactive interpreter  
> > > > > > > > within the\*  
> > > > > > > > \* running service process using `nameko  
> > > > > > > > backdoor`.\*
> > > > > > > > 
> > > > > > > > if not, have a look at the source for the same
> > > > > > > > 
> > > > > > > > Best,  
> > > > > > > > David
> > > > > > > > 
> > > > > > > > On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> > > > > > > > 
> > > > > > > > > Hi devs
> > > > > > > > > 
> > > > > > > > > We''re experiencing hanging services in production. Previously I've  
> > > > > > > > > used the eventlet backdoor to telnet in and inspect what workers are in  
> > > > > > > > > flight and what they are executing, but I cannot remember the steps to do  
> > > > > > > > > this and it doesn't seem to be documented - at least not outside of the  
> > > > > > > > > nameko test suite.
> > > > > > > > > 
> > > > > > > > > Can you take us through the steps to do this please? starting from  
> > > > > > > > > defining the port in our config, telnetting in and then inspecting the live  
> > > > > > > > > objects to find what workers are executing what and with what call args?  
> > > > > > > > > We're using the HTTP entrypoints if that is important.
> > > > > > > > > 
> > > > > > > > > Thanks

---

<div class="post-metadata">

**Author:** ![David\_Szotten](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/david_szotten/32/6_2.png) [@David\_Szotten](https://discourse.nameko.io/u/David_Szotten)\
**Post date:** [April 5, 2017, 11:57am UTC](https://discourse.nameko.io/t/nameko-eventlet-back-door/184/10 "2017-04-05T11:57:00Z")

</div>

pull requests to the docs are always very welcome!

d

> **···**
>
> On Wednesday, 5 April 2017 12:54:47 UTC+1, simon harrison wrote:
> 
> > perfect! thanks chaps.
> > 
> > this sort of debugging know-how could find themselves a place in the docs?  
> > how would you feel about a Troubleshooting section?
> > 
> > On Wednesday, 5 April 2017 12:18:38 UTC+1, Matt Yule-Bennett wrote:
> > 
> > > \_worker\_threads is a dict of greenthreads keyed by the worker context for  
> > > each call. Inspecting the worker context will tell you everything about  
> > > that worker -- the entrypoint that fired, its arguments, context data etc.
> > > 
> > > Another tip is that you can inspect the greenthread itself to see what  
> > > it's currently doing. This is useful if your workers are hanging. Example:
> > > 
> > > ct = list(runner.containers)[0] # first container  
> > > gt = list(ct.\_worker\_threads.values())[0] # first worker greenthread
> > > 
> > > import traceback  
> > > traceback.print\_stack(gt.gr\_frame) # print current stack
> > > 
> > > You will find the thread sitting waiting for some I/O (it has to be in  
> > > order for your thread to be running). If the worker is hung it'll be the  
> > > same stack every time you check.
> > > 
> > > On Wednesday, April 5, 2017 at 12:04:24 PM UTC+1, simon harrison wrote:
> > > 
> > > > Cool. Making progress. Thanks for the help here.
> > > > 
> > > > We can get the container and then see ``\_worker\_threads``.
> > > > 
> > > > How can we see what entrypoint is being worked on by a worker? Is that  
> > > > even possible? Because that's what we're after here.
> > > > 
> > > > Thanks again!
> > > > 
> > > > On Wednesday, 5 April 2017 11:48:55 UTC+1, David Szotten wrote:
> > > > 
> > > > > the runner should be available (injected into locals):  
> > > > > [https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106](https://github.com/nameko/nameko/blob/master/nameko/cli/run.py#L106)
> > > > > 
> > > > > you're a bit limited since going via telnet/netcat, but rlwrap helps a  
> > > > > bit
> > > > > 
> > > > > d
> > > > > 
> > > > > On Wednesday, 5 April 2017 11:46:37 UTC+1, simon harrison wrote:
> > > > > 
> > > > > > What's the trick to get the python interpreter to behave?
> > > > > > 
> > > > > > ``apt-get install libreadline`` doesn't help.
> > > > > > 
> > > > > > Then we need to find the workers from the runner object.
> > > > > > 
> > > > > > On Wednesday, 5 April 2017 11:10:21 UTC+1, David Szotten wrote:
> > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'm afraid i can't tell if your problem is solved or if you are  
> > > > > > > looking for additional info/advice?
> > > > > > > 
> > > > > > > Best,  
> > > > > > > David
> > > > > > > 
> > > > > > > On Wednesday, 5 April 2017 11:08:39 UTC+1, simon harrison wrote:
> > > > > > > 
> > > > > > > > Hi David
> > > > > > > > 
> > > > > > > > Yes we are, and we are now specifying a backdoor port.
> > > > > > > > 
> > > > > > > > On Wednesday, 5 April 2017 10:26:57 UTC+1, David Szotten wrote:
> > > > > > > > 
> > > > > > > > > Are you running your services with `nameko run`?
> > > > > > > > > 
> > > > > > > > > nameko run --help  
> > > > > > > > > usage: nameko run [-h] [--config CONFIG] [--broker BROKER]  
> > > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[\*--backdoor-port BACKDOOR\_PORT\*]  
> > > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;module[:service class] [module[:service class]  
> > > > > > > > > ...]
> > > > > > > > > 
> > > > > > > > > Run nameko services. Given a python path to a module containing one  
> > > > > > > > > or more  
> > > > > > > > > nameko services, will host and run them. By default this will try  
> > > > > > > > > to find  
> > > > > > > > > classes that look like services (anything with nameko entrypoints),  
> > > > > > > > > but a  
> > > > > > > > > specific service can be specified via ``nameko run  
> > > > > > > > > module:ServiceClass``.
> > > > > > > > > 
> > > > > > > > > positional arguments:  
> > > > > > > > > &nbsp;&nbsp;module[:service class]  
> > > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;python path to one or more service classes  
> > > > > > > > > to run
> > > > > > > > > 
> > > > > > > > > optional arguments:  
> > > > > > > > > &nbsp;&nbsp;-h, --help show this help message and exit  
> > > > > > > > > &nbsp;&nbsp;--config CONFIG The YAML configuration file  
> > > > > > > > > &nbsp;&nbsp;--broker BROKER RabbitMQ broker url  
> > > > > > > > > \* --backdoor-port BACKDOOR\_PORT\*  
> > > > > > > > > \* Specify a port number to host a backdoor,  
> > > > > > > > > which can be\*  
> > > > > > > > > \* connected to for an interactive  
> > > > > > > > > interpreter within the\*  
> > > > > > > > > \* running service process using `nameko  
> > > > > > > > > backdoor`.\*
> > > > > > > > > 
> > > > > > > > > if not, have a look at the source for the same
> > > > > > > > > 
> > > > > > > > > Best,  
> > > > > > > > > David
> > > > > > > > > 
> > > > > > > > > On Wednesday, 5 April 2017 10:22:06 UTC+1, simon harrison wrote:
> > > > > > > > > 
> > > > > > > > > > Hi devs
> > > > > > > > > > 
> > > > > > > > > > We''re experiencing hanging services in production. Previously  
> > > > > > > > > > I've used the eventlet backdoor to telnet in and inspect what workers are  
> > > > > > > > > > in flight and what they are executing, but I cannot remember the steps to  
> > > > > > > > > > do this and it doesn't seem to be documented - at least not outside of the  
> > > > > > > > > > nameko test suite.
> > > > > > > > > > 
> > > > > > > > > > Can you take us through the steps to do this please? starting from  
> > > > > > > > > > defining the port in our config, telnetting in and then inspecting the live  
> > > > > > > > > > objects to find what workers are executing what and with what call args?  
> > > > > > > > > > We're using the HTTP entrypoints if that is important.
> > > > > > > > > > 
> > > > > > > > > > Thanks