Utiliser un ordinateur portable ipython via SSH donne l'erreur GLIBC introuvable

Question

J'essaye d'exécuter ipython portable via SSH dans un virtualenv précédemment créé sur l'ordinateur directement connecté (pas de SSH). Ce faisant le bloc-notes ipython échoue avec:

(venv2) [host]user: ipython notebook --nobrowser 

Traceback (most recent call last): 
    File ".../venv2/bin/ipython", line 11, in <module> 
    sys.exit(start_ipython()) 
    File ".../venv2/lib/python2.7/site-packages/IPython/__init__.py", line 118, in start_ipython 
    return launch_new_instance(argv=argv, **kwargs) 
    File ".../venv2/lib/python2.7/site-packages/traitlets/config/application.py", line 591, in launch_instance 
    app.initialize(argv) 
    File "<decorator-gen-111>", line 2, in initialize 
    File ".../venv2/lib/python2.7/site-packages/traitlets/config/application.py", line 75, in catch_config_error 
    return method(app, *args, **kwargs) 
    File ".../venv2/lib/python2.7/site-packages/IPython/terminal/ipapp.py", line 305, in initialize 
    super(TerminalIPythonApp, self).initialize(argv) 
    File "<decorator-gen-7>", line 2, in initialize 
    File ".../venv2/lib/python2.7/site-packages/traitlets/config/application.py", line 75, in catch_config_error 
    return method(app, *args, **kwargs) 
    File ".../venv2/lib/python2.7/site-packages/IPython/core/application.py", line 386, in initialize 
    self.parse_command_line(argv) 
    File ".../venv2/lib/python2.7/site-packages/IPython/terminal/ipapp.py", line 300, in parse_command_line 
    return super(TerminalIPythonApp, self).parse_command_line(argv) 
    File "<decorator-gen-4>", line 2, in parse_command_line 
    File ".../venv2/lib/python2.7/site-packages/traitlets/config/application.py", line 75, in catch_config_error 
    return method(app, *args, **kwargs) 
    File ".../venv2/lib/python2.7/site-packages/traitlets/config/application.py", line 487, in parse_command_line 
    return self.initialize_subcommand(subc, subargv) 
    File "<decorator-gen-3>", line 2, in initialize_subcommand 
    File ".../venv2/lib/python2.7/site-packages/traitlets/config/application.py", line 75, in catch_config_error 
    return method(app, *args, **kwargs) 
    File ".../venv2/lib/python2.7/site-packages/traitlets/config/application.py", line 418, in initialize_subcommand 
    subapp = import_item(subapp) 
    File ".../venv2/lib/python2.7/site-packages/ipython_genutils/importstring.py", line 31, in import_item 
    module = __import__(package, fromlist=[obj]) 
    File ".../venv2/lib/python2.7/site-packages/notebook/notebookapp.py", line 32, in <module> 
    from zmq.eventloop import ioloop 
    File ".../venv2/lib/python2.7/site-packages/zmq/__init__.py", line 44, in <module> 
    _libsodium = ctypes.CDLL(bundled_sodium[0], mode=ctypes.RTLD_GLOBAL) 
    File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__ 
    self._handle = _dlopen(self._name, mode) 
    OSError: /lib64/libc.so.6: version 'GLIBC_2.14' not found (required by .../venv2/lib/python2.7/site-packages/zmq/libsodium.so) 
    linux-vdso.so.1 => (0x00007ffc957cf000) 
    libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007ffa27a84000) 
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ffa27867000) 
    libc.so.6 => /lib64/libc.so.6 (0x00007ffa274d2000) 
    libdl.so.2 => /lib64/libdl.so.2 (0x00007ffa272ce000) 
    libutil.so.1 => /lib64/libutil.so.1 (0x00007ffa270cb000) 
    libm.so.6 => /lib64/libm.so.6 (0x00007ffa26e46000) 
    /lib64/ld-linux-x86-64.so.2 (0x0000003f10400000) 
    symbol memcpy, version GLIBC_2.14 not defined in file libc.so.6 with link time reference (.../venv2/lib/python2.7/site-packages/zmq/libsodium.so) 

Et ldd donne:

(venv2) [host]user: ldd -r -v .../venv2/lib/python2.7/site-packages/zmq/libsodium.so 
.../venv2/lib/python2.7/site-packages/zmq/libsodium.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by .../venv2/lib/python2.7/site-packages/zmq/libsodium.so) 
    linux-vdso.so.1 => (0x00007ffd835e7000) 
    libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007f229227b000) 
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f229205e000) 
    libc.so.6 => /lib64/libc.so.6 (0x00007f2291cc9000) 
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f2291ac5000) 
    libutil.so.1 => /lib64/libutil.so.1 (0x00007f22918c2000) 
    libm.so.6 => /lib64/libm.so.6 (0x00007f229163d000) 
    /lib64/ld-linux-x86-64.so.2 (0x0000003f10400000) 
symbol memcpy, version GLIBC_2.14 not defined in file libc.so.6 with link time reference (.../venv2/lib/python2.7/site-packages/zmq/libsodium.so) 

    Version information: 
    .../venv2/lib/python2.7/site-packages/zmq/libsodium.so: 
     libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0 
     libc.so.6 (GLIBC_2.14) => not found 
     libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 
    /usr/lib64/libpython2.7.so.1.0: 
     libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2 
     libutil.so.1 (GLIBC_2.2.5) => /lib64/libutil.so.1 
     libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0 
     libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6 
     libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 
    /lib64/libpthread.so.0: 
     ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 
     ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2 
     ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 
     libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 
    /lib64/libc.so.6: 
     ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 
     ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 
    /lib64/libdl.so.2: 
     ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 
     libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 
    /lib64/libutil.so.1: 
     libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 
    /lib64/libm.so.6: 
     libc.so.6 (GLIBC_PRIVATE) => /lib64/libc.so.6 
     libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6 

Lors de l'utilisation ipython portable via bureau normal connexion il toutes les œuvres, mais l'utiliser via SSH donne toujours cette erreur. Réinstaller le venv via SSH n'a pas aidé. Je n'ai pas d'accès root et je n'ai pas sudo.

Des idées pour le faire fonctionner?

Merci beaucoup!

Answer 1

De https://docs.python.org/3/library/venv.html:

The venv module provides support for creating lightweight “virtual environments” 
with their own site directories, optionally isolated from system 
site directories. 

Apparemment, votre environnement virtuel est isolé du système, et aussi utilise une version plus ancienne de la glibc. La partie SSH de votre question est probablement un faux-fuyant, c'est le venv qui cause vos problèmes, pas ssh.

Vous pouvez trouver la version de la glibc à l'intérieur et à l'extérieur de venv en exécutant /lib64/libc.so.6.

Une fois que vous confirmez que libc.so.6 à l'intérieur venv est plus vieux que 2.14 ... il y a très peu que vous pouvez faire pour résoudre ce problème.

Vous pouvez travailler avec celui qui maintient votre venv pour mettre à jour GLIBC à l'intérieur de celui-ci mis à jour pour correspondre au système un, ou vous pouvez essayer de créer des binaires qui ne nécessitent pas GLIBC-2.14.

Cette dernière solution est non triviale. Deux approches courantes consistent à compiler/lier vos binaires à l'intérieur d'un environnement chroot, ou en utilisant un compilateur croisé linux-to-old-linux.

Une approche plus viable pourrait être de toujours construire vos binaires à l'intérieur le venv. Ils vont ensuite travailler à l'intérieur et à l'extérieur de celui-ci.