Kenneth Martin | 7 Jan 21:03 2015

Finally getting where I can replicate problems with stockquotes phase3 tutorial

I've been going back and forth a number of times and I can now replicate 

Details: running Debian Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 
01:36:09 UTC 2014 armv7l GNU/Linux
on a Beaglebone Black C.
Pyro4: 4.31

1) Tutorial works fine with serpent serializer.

2) I have not spent time to figure out if I need to set environment 
in all three terminals or just in terminal with, or in 
both terminals with and, but for tests, I 
am setting in all three terminal windows to be sure. (actually see j 
below - I did spend some time and it appears only terminal 0 needs the 
environment variable). I also change
Pyro4.config.SERIALIZER = 'pickle'
in all three files

3) Note: even with serpent, tutorial does not work with
     Pyro4.config.COMMTIMEOUT = 4.0
I believe problem is with and error message is not getting 
enough data (probably from

4) After running successfully with serpent, and going back to running 
with pickle;
a) I stop all programs including name server.
b) I set environment variables in all three terminals
(Continue reading)

Kenneth Martin | 7 Jan 00:06 2015

locateNS() hangs when running stockquotes example in tutorial

Disclaimer, I'm brand new to Pyro4 and may be doing something stupid.
Details: running Debian Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux
on a Beaglebone Black C.
Pyro4: 4.31

I set the environment variable per tutorial:
export PYRO_SERIALIZERS_ACCEPTED=pickle, but I may have done this after running >pyro4-ns &

When running the stockquote tutorial phase 3, I determined using winpdb that was hanging on line 34
    ns = Pyro4.locateNS()

I then changed serializer to serpent (environment variables and code in three programs and example worked),
I then changed back to pickle, and now it worked.
I'm guessing that I may have started the nameserver before I set the environment variable, but if I now unset it,
I get lots of errors when starting the nameserver so I can't replicate it.

When it was hanging, I believe it was hanging while waiting to acquire a lock starting with __, in a release function, but since I
can't replicate it, I can't be more exact.

Summary, there may be a problem with the tutorial in 4.31 in an out of the box set-up.
Also, maybe some checks for consistency on serializers might help. Not sure if this helps, but for new users having the tutorials
work is so critical, I thought it might be worth taking the time, as Pyro4 looks like a great module; Irmen, much appreciated.


Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now.
Pyro-core mailing list
Irmen de Jong | 13 Dec 00:21 2014

Pyro 4.31 released!


Pyro 4.31 has just been released!

Get it from Pypi:
Or straight from Github:


locateNS now properly sets provided hmac key on proxy returned via broadcast lookup
terminate call added to flame remoteconsole

Have fun!

Irmen de Jong

Bzzzz | 12 Nov 19:59 2014

Some questions

debian sid
python Ver. 2.7.8

Hi list,

First, I'm not really a programmer, even though I did some C and
assembly language some decades ago (so not on the head… nor the balls;)

I've upgraded to 4.30 and try to use HMAC signature; my client is working
with one block of code, but not with the other one - I followed the
docs but I may not have understood it correctly:

ns = Pyro4.naming.locateNS()
ns._pyroHmacKey = conf_cli.HMAC_KEY
uri = ns.lookup( "rpc.server" )
DB = Pyro4.core.Proxy( uri )
DB._pyroHmacKey = conf_cli.HMAC_KEY
DB._pyroTimeout = 30.0
db_hash, _RIGHTS = DB.getRights( cli_db, cli_port, cli_user, cli_passwd,
    cli_host )

DB = Pyro4.core.Proxy( "PYRONAME:rpc.server" )
    (BTW, as NS also have the same hmac key, how is it able to answer
    that without throwing an error as there's no key in parms?)
DB._pyroHmacKey = conf_cli.HMAC_KEY
    Here, when calling the remote object, I've got this error:
cannot connect: hmac key config not symmetric

This is a problem as some remote objects will be called a lot of time
and docs says my first method will overload the NS by multiple calls.

My other question is: if I log Pyro4 at debug level, I can see 
clients' IP addresses; how can I retrieve them into my server?


Bali dit : Erf, I'm sure you're drunk again…
Nawo dit : nooooooooo!!! Nto true
Bali dit : recite me the alphabet then ;D
Nawo dit : azertyuiopqsdfghjklmwxcvbn
Bali dit : … I'm at lost for words…

Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
Pyro-core mailing list
Pyro-core <at>
Irmen de Jong | 8 Nov 22:56 2014

Pyro 4.30 released! name server persistency.


Pyro 4.30 has just been released!

Get it from Pypi:
Or straight from Github:


Persistent name server option: -s (currently implemented: dbm, sqlite, and the
default volatile in-memory storage)
Name server utility methods have new 'storage' parameter to customize storage mechanism
nsc got new 'lookup' command to get one single registration from the nameserver
removed ``HMAC_KEY`` config item (deprecated in 4.29), use the ``_pyroHmacKey``
property on proxy and daemon instead.
  This finalizes the change that allows you to have a per-proxy hmac key instead of a
single global one. (Also counts for daemons)
name server and nsc command line tools gained -k/--key option to specify hmac key
(just as the echoserver and flameserver already had)
name server locateNS and resolve methods gained hmac key parameter
configuration dump now also includes protocol version
message class now has a static convenience 'ping' method to send ping messages.
Useful for instance in the 'disconnects' example.

Have fun!

Irmen de Jong

Borek Patzak | 7 Nov 08:48 2014

Re: Serialization of return value (2)

 >> >Hello,
 >> >I have encountered a strange problem with return value from remote
 >> >class, when using pickle protocol.
 >> >When type of return value is a class, then depending whether it is
 >> >derived from object base or not, the return value is different.
 >> >When I run a client, the following response is received:
 >> >$ python
 >> >Uri:PYRO:obj_58a48bb0def74534b8749c6b10d3fa8b@...:9091
 >> >Server: <Pyro4.core.Proxy at 0x7f1592605510, not connected, for
 >> >PYRO:obj_58a48bb0def74534b8749c6b10d3fa8b@...:9091>
 >> >a:PYRO:obj_140031e8eb8f4eaf881a2922b49738c5@...:9091
 >> >b: <Pyro4.core.Proxy at 0x7f1592605610, not connected, for
 >> >PYRO:obj_140031e8eb8f4eaf881a2922b49738c5@...:9091>
 >> >finished
 >> >
 >> >1) is this intended behaviour?
 > Yes, this is Pyro's autoproxying behavior which is turned on by default.
 > See
 >> >2) for classes derived from object base, can the the type of return
 >> >value (local copy instead of URI) changed?
 > Yes, disable the autoproxy setting.
 > Anyway you should not use old-style classes really. Pyro4 won't 
support them. I guess
 > I'll have to add a check in the daemon that prevents registering 
old-style class instances.
 > Irmen

Hi Irmen,

thank you for your answer. I have two follow up questions:
1) From the docs I understood that autoproxy feature affects how
pyro objects are passed 
In the example I have provided at the beginning this post thread, the 
class attribute has not been registered, so its not a pyro objects. It 
is being returned and the return value (copy or proxy) is affected by 
autoproxy setting. Does this mean that if class is registered then all 
attributes are registered as well?

2) In my speficif case, the autoproxy ON is ok, but in some specific 
cases I would like to receive a copy instead of proxy object. Could be 
autoproxy behaviour altered for specific call or what is the suggested 
way to get a copy?


Dick Kniep | 6 Nov 22:30 2014

Serpent serializer

Hi List,

I tried to pass an odt document as a field in Pyro using serpent. Now it seems that serpent encodes the zip
which screws it up..... Any idea how I can solve this?

D. Kniep

Irmen de Jong | 6 Nov 22:36 2014

persistent name server option coming in 4.30


For the next version I've started to add a persistency feature to the name server.
It's starting to take shape pretty well I think, I've just committed stuff that adds a
'-s' (storage) option to the name server where you can select the storage type to use.
Default is still the volatile in-memory storage, but you can also specify
"dbm:nameserver.dbm" to let the nameserver store its registry in a persistent dbm
datafile on disk. Next time you run the nameserver it will remember all registrations :)
I'm planning on adding a sqlite based storage option as well because the dbm one doesn't
scale (dbm doesn't allow concurrent access).


Irmen de Jong | 28 Oct 22:55 2014

Pyro 4.29 released!


Pyro 4.29 has just been released!

Get it from Pypi:
Or straight from Github:


HMAC_KEY config item is deprecated, will be removed in next version
set hmac key directly on proxy._pyroHmacKey property, this makes per-proxy hmac keys
removed support for server side object traversal using dotted names such as a.b.c.d
(has been deprecated since 4.27)
removed DOTTEDNAMES config item (has been deprecated since 4.27)
removed support for setting proxy._pyroOneway() in client code (has been deprecated
since 4.27. You must depend on the metadata mechanism now, which is enabled by default)
Future and FutureResult then() methods now return itself, so they can be easiliy chained
added Future.iferror and FutureResult.iferror to handle exceptions (instead of
silently ignoring them)
fixed FutureResult.then to correctly evaluate all chained functions

Have fun!

Irmen de Jong

Francesco Petralia | 27 Oct 12:56 2014

[Errno 61] Connection refused when trying to call a remote object method

Hello all. I'm facing a new error, I try to give you an exhaustive explanation:

When I try to call a remote object error, the following error appears:

Traceback (most recent call last):
  File "/../ATLD/src/Pyro4/", line 407, in __pyroCreateConnection
    sock = socketutil.createSocket(connect=connect_location, reuseaddr=Pyro4.config.SOCK_REUSE, timeout=self.__pyroTimeout)
  File "/../ATLD/src/Pyro4/", line 320, in createSocket
ConnectionRefusedError: [Errno 61] Connection refused

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/../ATLD/src/", line 298, in start_analysis
    results = self.proxy[0].get_results()
  File "/../ATLD/src/Pyro4/", line 231, in __getattr__
  File "../ATLD/src/Pyro4/", line 457, in _pyroGetMetadata
  File "../ATLD/src/Pyro4/", line 423, in __pyroCreateConnection
    raise ce
Pyro4.errors.CommunicationError: cannot connect: [Errno 61] Connection refused

I really don't understand what's going on.

Object are successfully registered, this is the first think that I've checked:
<Pyro4.core.Proxy at 0x104953438, connected, for PYRO:Pyro.NameServer <at> localhost:9090>

python3 -m Pyro4.nsc list gives this output:

--------START LIST 

Pyro.NameServer --> PYRO:Pyro.NameServer <at>

My_Object_0 -->

--------END LIST 

I also tried to telnet on port 51106

>>>telnet 51106


>>>telnet: connect to address Connection refused

>>>telnet: Unable to connect to remote host

Here's some code inside my Object class:

daemon = Pyro4.Daemon(analyzer.get_ip_address())

uri_text_analyzer = daemon.register(analyzer)

 __NS__.register(__PYRO_OBJ_NAME__, uri_text_analyzer)


In another module I have:

ns = Pyro4.naming.locateNS()
uri_text_analyzer = ns.lookup(self.my_object_name + str(identifier))
#This following line is the one that raises the error
results = self.proxy[0].get_results()

Further specs: I'm running it on Mac OS X Yosemite, with Python3.4 and PyRO4.
If you need other infos feel free to ask.

Thanks in advance for your help.

Pyro-core mailing list
Irmen de Jong | 26 Oct 23:06 2014

future chain not always fully evaluated


There seems to be a bug in Pyro's future implementation, the chained (then) functions
are not always fully evaluated:

Until this is fixed it's better to not use Future.then()/FutureResult.then().