> Hello,
>
> I'm working with a chroted environment, in which the chroot system was
> deboostraped using Debian Testing, but the host has a Debian Stable,
> after launch a django application that use the mysql module it raise
> the next error:
>
> Error loading MySQLdb module: /lib/libnsl.so.1: symbol
> __libc_clntudp_bufcreate, version GLIBC_PRIVATE not defined in file
> libc.so.6 with link time reference
>
> Looking for the error I'd found this:
>
> The problem is that during glibc upgrade some daemons/long running
> programs
> might be dynamically linked against the older glibc, but not have all the
> libraries dlopened, then glibc (or any other library) is upgraded and then
> the
> daemon/long running program dlopens libnsl or some othernew library. The
> old
> libc.so the program has loaded obviously doesn't have the new symbol, so
> dlopen
> fails.
>
> As uwsgi is running on the stable environment has the glibc of
> stable(2.7-18lenny7) and the chrooted module of mysql ask for the
> glibc of testing(2.11.2-7: amd64). I checked the host machine and libc
> doesn't have the symbol in the version GLIBC_PRIVATE
>
> # objdump -T /lib/libc.so.6 | grep clntudp_bufcreate
> 00000000000f2420 g DF .text 0000000000000332 GLIBC_2.2.5
> clntudp_bufcreate
>
> And the chrooted have it:
>
> # objdump -T /lib/libc.so.6 | grep clntudp_bufcreate
> 00000000000f3410 g DF .text 000000000000002f GLIBC_2.2.5
> clntudp_bufcreate
> 00000000000f3640 g DF .text 00000000000003e9 GLIBC_PRIVATE
> __libc_clntudp_bufcreate
>
> I tried to import by hand the python module inside the chroot and it
> works, after that i check the /proc/<pid>/maps of uwsgi, and it links
> to libc-2.7.so (which is the version of debian stable), but executing
> python inside the chroot i get libc.2.11 (debian testing).
>
> It is possible to run uwsgi using chroot and somehow use the libraries
> from the chrooted system? I don't want to move my host to testing, or
> move my chroooted system to stable, because of security in the first
> case and app version in the second.
>
> Thanks.
>
>
Make a copy of the uWSGI binary into the chroot, and issue a reload in
your python module checking if it is the first run:
import os
import uwsgi
reloads = os.environ.get('UWSGI_RELOADS', '0')
# is this the uWSGI binary in the main system ?
if reloads == 0:
uwsgi.reload()
application = xxxxxxx
Then reload() will re-run uwsgi in the chroot
WARNING: try to maintain the same path of uWSGI for stable and testing
otherwise the reloading cannot found the new binary. If you cannot do it
set the path of the chrooted-binary with the --binary-path option
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
