I cannot reproduce this issue. For example, I have /tmp/test.pyc which is the python-compiled version of 'os.system("lsb_release -a"); time.sleep(30);'. Running it directly should trigger binfmt since the magic matches:
$ hexdump -C /tmp/test.pyc | head -n1 00000000 d1 f2 0d 0a fd 34 ad 4a 63 00 00 00 00 00 00 00 |.....4.Jc.......| $ cat /proc/sys/fs/binfmt_misc/python2.6 enabled interpreter /usr/bin/python2.6 flags: offset 0 magic d1f20d0a
It does run, but it's running in the chroot (reports "jaunty" not "karmic"), and the executable launched is inside the chroot too:
$ ps auwwx | grep test kees 10858 0.1 0.0 19028 3508 pts/9 S+ 11:13 0:00 /usr/bin/python2.6 ./test.pyc $ ls -la /proc/10858/exe lrwxrwxrwx 1 kees kees 0 2009-09-13 11:13 /proc/10858/exe -> /var/lib/schroot/mount/jaunty-3f106f9a-a37c-4a3f-b413-76b63fc51f79/usr/bin/python2.6
I cannot reproduce this issue. For example, I have /tmp/test.pyc which is the python-compiled version of 'os.system( "lsb_release -a"); time.sleep(30);'. Running it directly should trigger binfmt since the magic matches:
$ hexdump -C /tmp/test.pyc | head -n1 fs/binfmt_ misc/python2. 6
00000000 d1 f2 0d 0a fd 34 ad 4a 63 00 00 00 00 00 00 00 |.....4.Jc.......|
$ cat /proc/sys/
enabled
interpreter /usr/bin/python2.6
flags:
offset 0
magic d1f20d0a
It does run, but it's running in the chroot (reports "jaunty" not "karmic"), and the executable launched is inside the chroot too:
$ ps auwwx | grep test schroot/ mount/jaunty- 3f106f9a- a37c-4a3f- b413-76b63fc51f 79/usr/ bin/python2. 6
kees 10858 0.1 0.0 19028 3508 pts/9 S+ 11:13 0:00 /usr/bin/python2.6 ./test.pyc
$ ls -la /proc/10858/exe
lrwxrwxrwx 1 kees kees 0 2009-09-13 11:13 /proc/10858/exe -> /var/lib/