10. Errors and Troubleshooting

The Troubleshooting section provides various hints and tips when you can't get things to work as expected.

The Specific issues section at the end contains more detailed discussion of specific issues you may encounter:

• 127.0.0.1 connection problems
• problems when using user defined exception classes

Pyro Errors

Pyro Exception Hierarchy

• Exception
  • PyroError
    • URIError
    • DaemonError
    • NamingError
    • NoModuleError
    • ProtocolError
      • ConnectionClosedError
        • TimeoutError
      • ConnectionDeniedError

Pyro's exception extensions

• Providing the remote exception traceback (the actual error that occurred in the Pyro object) as an attribute on the local exception object. You can print this using the util.getPyroTraceback function for instance.
• Printing a very detailed traceback, including the names and values of current local variables at the moment of the exception. See the PYRO_DETAILED_TRACEBACK config item. This one is disabled by default because of security reasons.
• You can set a custom excepthook in sys.excepthook to automatically print any remote exception tracebacks that might be part of an exception. The hook is provided as Pyro.util.excepthook.

What error occurs where and when?

Initialization

Name Server

PyroError-- The NameServerLocator raises PyroError "Name Server not responding" if it failed to discover the Name Server (via the getNS method).

Also, the PYROAdapter raises NoModuleError "No module named XYZ" if it cannot import a Python module. See below in the table.

Also, the startup code in configuration.py raises PyroError "Error reading config file" if Pyro's configuration file cannot be read.

Pyro Core

DaemonError-- The Daemon object raises DaemonError "Couldn't start Pyro daemon" if it was unable to start. This usually means that the required network port (socket) is temporarily unavailable because another Pyro daemon is already running on it.

PYRO Protocol adapter

Util

Troubleshooting

Use python -m Pyro.configuration to get a printout of Pyro's active configuration settings.

Specific issues

127.0.0.1 connection problems

Sometimes you may encounter a problem with connecting to your Pyro server over the network, and Pyro complains that it cannot connect to your server. If you see some complaints about '127.0.0.1', 'localhost' or 'loopback adapter' in the error or in the log, continue reading.

What is happening? Pyro has connected the server to 127.0.0.1 which is the local loopback network. This means that the server is not accessible from anything but the local host. Pyro code on a different host can never make a connection to this server because even if it obtains an URI from the server, the address in it will be 127.0.0.1 and that means: 'hey, I am on your local host'. It then tries to connect to the server on the local host, but that won't work for obvious reasons.

Why is this happening? You may have told Pyro to use the loopback address yourself, by setting the hostname to bind on to 'localhost' or '127.0.0.1'. That is fine as long as you're only running stuff on this single host, but if external machines try to connect to it it will fail. The other explanation is that the hostname Pyro uses to bind the server on, resolves (via DNS) to the IP address of the loopback adapter (127.0.0.1). Quite a few Linux distributions are set up like this unfortunately, where the hostname of your computer resolves to 127.0.0.1. (you can usually check this by typing ping yourhostname at a shell prompt). When Pyro tries to bind the server to a network adapter, it is then likely it ends up with 127.0.0.1.

What can I do about it? There are several options to fix this problem:

• Tell Pyro to bind on the correct network adapter / ip address. You can use an explicit 'host' parameter when creating the Daemon, if for instance you want to define it in your own config file. Like this: daemon=Pyro.core.Daemon(host="my.external.ip.address")
• There are several config items that may be of use here (See the Installation and Configuration chapter):
  • PYRO_HOST
  • PYRO_DNS_URI
  • PYRO_PUBLISHHOST
  • PYRO_NS_HOSTNAME
• Edit the /etc/hosts file on your system and fix the IP address that's associated with your hostname
• Fix your DNS server to return the correct IP address for your host if it returns 127.0.0.1
• Use the appropriate command line options for the Name Server or Event Server script tools to bind it to a different hostname.

Problems with user defined exception classes

In Python 2.5 and later, there is an issue with user-defined exceptions. Say you have a custom exception class written as follows:

class MyEx(Exception):
    def __init__(self, mymessage):
        self.mymessage=mymessage
    def __str__(self):
        return "[MyEx '%s']" % self.mymessage

If you are passing these exceptions over the wire in Pyro method calls, you will find that your program crashes with an error like this:

TypeError: ('__init__() takes exactly 2 arguments (1 given)', <class '__main__.MyEx'>, ())

This is not Pyro's fault: it is caused by a change in the Exception classes which was introduced in Python 2.5. This change seems to cause that Exception objects don't follow the usual pickle protocol. The unpickling of the exception object fails, because the __init__ method is called without any arguments (it shouldn't even be called at all by the way!). Unfortunately, you won't be able to fix this problem by writing a __getinitargs__ or __getnewargs__ method to force the correct parameters, because these methods won't be called. The easiest way to work around this problem now seems to change the init method so that it uses *args instead of a single argument (this is what the built in Exceptions seem to do), or change it a little so that it also works with zero arguments:

    def __init__(self, mymessage=None):
        self.mymessage=mymessage

If you don't need any special behavior of your own exception objects, it is probably best to just subclass them from Exception and not define any custom methods or properties. That avoids the problem as well. All builtin exceptions should accept a string argument to be used as the exception message, so there is no need to subclass the exception and add custom behavior as shown above, if you just want to remember a message string.