Problems with new /lib, rc.d, and uwsgi

syngin · 2012-07-19 04:19:21

I'm using uwsgi from AUR and prior to the upgrade of glibc, things were fine when starting the daemon via rc.d, i..e,

rc.d start uwsgid

I've configured a new server, upgraded everything, and have found that starting the daemon manually or via /etc/rc.d/uwsgid works, but using /usr/sbin/rc.d results in the following traceback from Python 2.7.3:

Python version: 2.7.3 (default, Apr 24 2012, 00:00:54)  [GCC 4.7.0 20120414 (prerelease)]
Traceback (most recent call last):
  File "/lib/python2.7/site.py", line 563, in <module>
    main()
  File "/lib/python2.7/site.py", line 545, in main
    known_paths = addusersitepackages(known_paths)
  File "/lib/python2.7/site.py", line 278, in addusersitepackages
    user_site = getusersitepackages()
  File "/lib/python2.7/site.py", line 253, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/lib/python2.7/site.py", line 243, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/lib/python2.7/sysconfig.py", line 521, in get_config_var
    return get_config_vars().get(name)
  File "/lib/python2.7/sysconfig.py", line 420, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/lib/python2.7/sysconfig.py", line 299, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open //include/python2.7/pyconfig.h (No such file or directory)

I've taken a quick look around and as best I can reckon (but cannot prove), something funky is happening to Python during its self-discovery phase; in particular (as is probably obvious), the platform include path is getting mangled. I've tried doing what rc.d does manually (env -i "VARS" "/etc/rc.d/uwsgid" "start"), but can't replicate the traceback. The rc script included with uwsgid isn't anything complicated; it does the usual sourcing of rc.conf, functions, and conf.d (which in turn specifies a couple of uwsgi variables) before starting uwsgi.

If anyone has any tips or pointers, that'd be great.

wizzrobe · 2012-07-20 15:19:53

Just ran into the same issue here using uwsgi. I am going to try rebuilding the latest and see what kind of progress I can make, but hopefully someone more knowledgeable has some insight.

phoric · 2012-07-21 01:53:22

Same problem here. I get the "invalid Python installation" error as described above, when running uwsgi from a startup script. Running it manually from a command line works fine.

IOError: invalid Python installation: unable to open //include/python2.7/pyconfig.h (No such file or directory)

Notice the double forward-slash here on the path. I get the same thing. I'm thinking this should say /usr/include/python2.7/pyconfig.h, but somewhere the path is getting messed up.

I did not use the AUR, rather I installed uwsgi using "pip2 install uwsgi".

Last edited by phoric (2012-07-21 02:45:32)

phoric · 2012-07-21 03:11:01

A ridiculous and temporary work-around involves creating a symlink:

sudo mkdir -p /include/python2.7
sudo ln -s /usr/include/python2.7/pyconfig.h /include/python2.7/pyconfig.h

phoric · 2012-07-21 19:43:32

I submitted a bug upstream (edit: closed since it doesn't seem to be uWSGI-specific).

Last edited by phoric (2012-07-28 23:45:21)

Peaceseeker · 2012-07-21 21:13:43

This isn't specific uWSGI, I have the same problem using GUFW in AUR (https://aur.archlinux.org/packages.php?ID=57480), from what it looks like something is broken in the python2 package in extra. The file '/usr/lib/python2.7/sysconfig.py' has 3 entries with '{platbase}', replacing that with '/usr', also seems to fix this bug, although that isn't the solution, it still points to something possibly broken in the python2 package, and the recent lib folder move seems to have something to do with it, I think.

progandy · 2012-07-21 21:32:43

This modification of /usr/lib/python2.7/sysconfig.py works for me. Somehow exec_prefix seems to be not correct.

_EXEC_PREFIX = '/usr' # os.path.normpath(sys.exec_prefix)

sys.exec_prefix should be /usr, and that is what the following command returns, too. Still, in sysconfig.py it is wrong:

python -c "import sys;import os;print (os.path.normpath(sys.exec_prefix))"

phoric · 2012-07-23 07:00:01

New bug report here: https://bugs.archlinux.org/task/30812

syngin · 2012-09-05 07:16:09

I've upgraded to systemd - problem persists. In fact, you can't even work around the problem with rc.local anymore (rc-local.service yields the same set of errors).

hbernier · 2012-09-14 16:11:46

I took a quick look at the bug report, slept on it, did some thinking, and added

 cd /etc

after the includes at the top of the uwsgid script that resides in /etc/rc.d/. I can now control execution via rc.d. I have not tested this with systemd.
Here's a patch for uwsgid.sh:
http://pastebin.com/rp8PYKbq

Arch Linux

#1 2012-07-19 04:19:21

Problems with new /lib, rc.d, and uwsgi

#2 2012-07-20 15:19:53

Re: Problems with new /lib, rc.d, and uwsgi

#3 2012-07-21 01:53:22

Re: Problems with new /lib, rc.d, and uwsgi

#4 2012-07-21 03:11:01

Re: Problems with new /lib, rc.d, and uwsgi

#5 2012-07-21 19:43:32

Re: Problems with new /lib, rc.d, and uwsgi

#6 2012-07-21 21:13:43

Re: Problems with new /lib, rc.d, and uwsgi

#7 2012-07-21 21:32:43

Re: Problems with new /lib, rc.d, and uwsgi

#8 2012-07-23 07:00:01

Re: Problems with new /lib, rc.d, and uwsgi

#9 2012-09-05 07:16:09

Re: Problems with new /lib, rc.d, and uwsgi

#10 2012-09-14 16:11:46

Re: Problems with new /lib, rc.d, and uwsgi

Board footer