Page MenuHomePhabricator

BUB 503: AttributeError: 'module' object has no attribute 'python_2_unicode_compatible'
Closed, ResolvedPublic

Description

https://tools.wmflabs.org/bub/ 503s. Reported by https://twitter.com/giovannidamiola/status/771448122371219456

tools.bub@tools-bastion-03:~$ webservice start
Traceback (most recent call last):
  File "/usr/local/bin/webservice", line 7, in <module>
    from toollabs.webservice.backends import Backend, GridEngineBackend, KubernetesBackend
  File "/usr/lib/python2.7/dist-packages/toollabs/webservice/backends/__init__.py", line 3, in <module>
    from toollabs.webservice.backends.kubernetesbackend import KubernetesBackend
  File "/usr/lib/python2.7/dist-packages/toollabs/webservice/backends/kubernetesbackend.py", line 3, in <module>
    import pykube
  File "/usr/lib/python2.7/dist-packages/pykube/__init__.py", line 8, in <module>
    from .objects import (  # noqa
  File "/usr/lib/python2.7/dist-packages/pykube/objects.py", line 16, in <module>
    @six.python_2_unicode_compatible
AttributeError: 'module' object has no attribute 'python_2_unicode_compatible'

Event Timeline

Nemo_bis renamed this task from AttributeError: 'module' object has no attribute 'python_2_unicode_compatible' to BUB 503: AttributeError: 'module' object has no attribute 'python_2_unicode_compatible'.Sep 2 2016, 7:48 AM
Nemo_bis updated the task description. (Show Details)

BUB has been down for almost one month now due to this Labs bug.

This is because the user seems to have modified their PYTHONPATH in their bashrc to something else:

tools.bub@tools-bastion-03:~$ echo $PYTHONPATH
:/data/project/bub/public_html/BUB/digi-lib:/data/project/bub/public_html/BUB/utils

Default changes to PYTHONPATH will cause system python scripts / libraries to stop working, as you can see. Please reset that and it should work fine.

valhallasw claimed this task.
valhallasw subscribed.

If you don't want to remove your PYTHONPATH setting, you can use

python -E -s `which webservice` start

instead. I've done so for you now.

This just happened again. One of the maintainers needs to sort out the PYTHONPATH issue :)

The long invocation time for jsub, webservice, etc. comes IMHO as a side-effect of this task (or T147350 for the general case); example:

tools.bub@tools-services-02:~$ time webservice restart
Traceback (most recent call last):
  File "/usr/local/bin/webservice", line 7, in <module>
    from toollabs.webservice.backends import Backend, GridEngineBackend, KubernetesBackend
  File "/usr/lib/python2.7/dist-packages/toollabs/webservice/backends/__init__.py", line 3, in <module>
    from toollabs.webservice.backends.kubernetesbackend import KubernetesBackend
  File "/usr/lib/python2.7/dist-packages/toollabs/webservice/backends/kubernetesbackend.py", line 3, in <module>
    import pykube
  File "/usr/lib/python2.7/dist-packages/pykube/__init__.py", line 8, in <module>
    from .objects import (  # noqa
  File "/usr/lib/python2.7/dist-packages/pykube/objects.py", line 16, in <module>
    @six.python_2_unicode_compatible
AttributeError: 'module' object has no attribute 'python_2_unicode_compatible'

real    1m44.094s
user    0m0.323s
sys     0m7.950s
tools.bub@tools-services-02:~$ time python -E -s `which webservice` restart
Your job is not running, starting.

real    0m1.692s
user    0m0.186s
sys     0m0.151s
tools.bub@tools-services-02:~$
scfc reassigned this task from valhallasw to bd808.

This works now thanks to T147350:

tools.bub@tools-bastion-03:~$ time webservice restart
Restarting webservice...............

real    0m17.059s
user    0m0.354s
sys     0m0.400s
tools.bub@tools-bastion-03:~$

I had initially read:

This is because the user seems to have modified their PYTHONPATH in their bashrc to something else:

tools.bub@tools-bastion-03:~$ echo $PYTHONPATH
:/data/project/bub/public_html/BUB/digi-lib:/data/project/bub/public_html/BUB/utils

Default changes to PYTHONPATH will cause system python scripts / libraries to stop working, as you can see. Please reset that and it should work fine.

to mean that all changes to PYTHONPATH cause failures. That was apparently not the problem here: Calling the old webservice with PYTHONPATH unset exhibited the same behaviour. The problem was caused by user-installed Python modules like /data/project/bub/.local/lib/python2.7/site-packages/six-1.4.1-py2.7.egg that shadowed the system module python-six 1.9.0-1~trusty1, used by python-pykube. So the part of T147350 that fixed this issue was #!/usr/bin/python -s, not #!/usr/bin/python -E.