Free Ubuntu-ers. I have a strange problem which I've spent a while trying to debug, and later I searched fairly thoroughly for data on it, without any luck.

I have a fairly new server running Lucid Lynx and I'm attempting to switch the default Python version to 2.7. I've tested all the apps that I'm running and they seem to run well on 2.7 - and it's not a mission-critical server, so I can fail and back out if I like.

I did my homework, installed 2.7, changed the soft links in /usr/bin, and edited my /usr/share/python/debian_defaults to make the default-version python2.7. Then I tried "python" from the command line for "root" and for "some random user account" and got python 2.7 and dusted my hands off.

This was a couple of months ago, and all has worked fine until today...

I tried to run a Python daemon - but it kept failing mysteriously. I tracked it down to a package that wasn't installed - but it was...

After some debugging, I discovered that in fact when I run a Python script as a daemon, it's running Python 2.6.5 - but if I run the same script from the command line, it's running Python 2.7.2 - and I of course haven't installed the new library for Python 2.6. (I'm using the Python daemon library to launch the script as a daemon...)

But my scripts all start with #!/usr/local/bin/python, the version I recently installed, and /usr/local/bin/python --version returns 2.7.2. In fact, I changed the #! line to explicitly point to python 2.7 and it still fails in exactly the same way.

Later, I discovered if I ran the program in pdb, the python debugger, I also get 2.6 as the version.

I think the key is that neither pdb nor the daemon runner pay any attention to the #! line - but I can't get any further than that.

Your kind help is gratefully solicited.

EDIT: Some good suggestions below - if my Stackoverflow karma reached here, I'd upvote them - but no good results (see comments below). Resolution: dump Python 2.6.

4 Answers 4


Try sudo update-alternatives --config python

Ubuntu/Debian has an alternatives system that it uses in the case that there are multiple programs that do the same thing. See man 8 update-alternatives for more information.

  • Felt I was close, but no. Got the error "no alternative for python" when using that command line. Searching found this article - and that got update-alternatives to work without error BUT it did not effect the change I needed! It switches back and forth without a trouble for the command line - daemons still have the issue. New strategy - dump Python 2.7 altogether, reinstall all my packages in Python 2.6 and stay away till Oneiric. A shame, since I'm on 2.7 in appengine and on my home machine. Thanks so much tho!
    – Tom Swirly
    Commented Mar 13, 2012 at 4:06

I don't have a silver bullet, but I do have a couple suggestions. When I run the following command:

$ ls -al /usr/bin/pdb*

I get this (I'm on Ubuntu 11.10):

lrwxrwxrwx 1 root root  6 2012-02-16 20:53 /usr/bin/pdb -> pdb2.7
lrwxrwxrwx 1 root root 23 2012-02-01 09:17 /usr/bin/pdb2.5 -> ../lib/python2.5/pdb.py
lrwxrwxrwx 1 root root 23 2011-08-11 06:04 /usr/bin/pdb2.6 -> ../lib/python2.6/pdb.py
lrwxrwxrwx 1 root root 23 2012-02-16 20:53 /usr/bin/pdb2.7 -> ../lib/python2.7/pdb.py

So for pdb, you may need to change the symlink.

You might also try this command (update-alternatives is in the repository if not already installed on your machine):

sudo update-alternatives --config python

This should clarify what your default version of python is and allow you to reset it.

Finally there are virtualenv and python-brew for explicitly controlling the python version you run on a system with multiple versions. I don't have any experience with python-brew, but I do like the way virtualenv packages neatly packages up python environments. If you're not familiar with it, this article may be of interest:


  • Thanks for the good try - see unfortunately my answer above. Love that second article too, will commit to memory. I appreciate the try and at least I now know about update-alternatives. be well!
    – Tom Swirly
    Commented Mar 13, 2012 at 4:07

I'm assuming you're trying to get upstart to play nicely with your python upgrade. Have you tried /usr/bin/python /opt/myservice.py? As others already mentioned update-alternatives is the way you're supposed to do it. They might not have applied it to upstart though.

  • I am indeed running it from the command line, but the Python daemon module restarts the program a second time as a daemon, and that time with Python 2.6. I didn't get past it (see above) but thanks for the help!
    – Tom Swirly
    Commented Mar 13, 2012 at 4:08
  • then you need to correct your python environment variables. it's a pain, but i'm pretty sure it's what you need to do Commented Mar 13, 2012 at 5:59

Eep. You are going well out of world of things you can change without serious breakage :)

Yes, you can compile and install any pythons you want in /usr/local, without any trouble. If you want one of them to be the python command, you can do that too, by putting such a symlink in /usr/local/bin/.

You really don't want to be touching /usr/share/python/debian_defaults, or messing with any of the symlinks in /usr/bin.

Are you running the daemon from upstart? Is /usr/local/bin maybe not in your PATH there?

  • Well, I think I've decided instead due to wise advice like yours to dump the whole idea of using Python 2.7 and bring in the parts I need from 2.7 into 2.6. While it's not dreadful if this server gets destabilized, there's a point where I'm just asking for extra work, and this is it.
    – Tom Swirly
    Commented Mar 13, 2012 at 4:53
  • Yeah, I mean obviously one can do anything one want to. But some things are maintainable and others are getting into the realm of crazy hackery :)
    – tumbleweed
    Commented Mar 13, 2012 at 10:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .