You are not logged in.

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

syngin
Member
From: Melbourne
Registered: 2011-03-29
Posts: 39

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

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.

Offline

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

wizzrobe
Member
Registered: 2007-03-22
Posts: 4

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

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.

Offline

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

phoric
Member
From: Seattle, WA
Registered: 2011-10-17
Posts: 19

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

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)

Offline

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

phoric
Member
From: Seattle, WA
Registered: 2011-10-17
Posts: 19

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

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

Offline

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

phoric
Member
From: Seattle, WA
Registered: 2011-10-17
Posts: 19

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

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)

Offline

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

Peaceseeker
Member
Registered: 2012-04-27
Posts: 23

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

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.

Offline

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

progandy
Member
Registered: 2012-05-17
Posts: 2,146

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

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))"

Offline

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

phoric
Member
From: Seattle, WA
Registered: 2011-10-17
Posts: 19

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

Offline

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

syngin
Member
From: Melbourne
Registered: 2011-03-29
Posts: 39

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

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).

Offline

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

hbernier
Member
Registered: 2010-08-07
Posts: 8

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

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

Offline

Board footer

Powered by FluxBB