I’m trying to make
pyodbc work with mssql17 odbc, but it’s failing as documented in this bug msodbc17: TCP Provider: Error code 0x10 · Issue #235407 · NixOS/nixpkgs · GitHub
I would like to try and tackle this until the maintainer of the package is heard back from, but I’m not sure where to start. Right now, I’m testing with
iusql which is a generic CLI for making connections to an SQL database using
unixodbc is a library that dynamically loads the
mssql17 ODBC library. When it tries to establish a connection with the port that docker opened to the mssql server, it fails.
This is only the case with the library packaged by nix
Outside of nix, the connection is established fine.
The nix package does some
patchelf magic nixpkgs/default.nix at e7603eba51f2c7820c0a182c6bbb351181caa8e7 · NixOS/nixpkgs · GitHub . It’s not clear to me how to check if that failed besides running
ldd, but that looks OK
$ ldd /nix/store/m72z6pjjgy2d4m3fsipl4jx18i2bwamx-msodbcsql17-22.214.171.124-1/lib/libmsodbcsql-17.7.so.1.1 linux-vdso.so.1 (0x00007ffc310f4000) libdl.so.2 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libdl.so.2 (0x00007f47a6410000) librt.so.1 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/librt.so.1 (0x00007f47a640b000) libodbcinst.so.2 => /nix/store/x156lay2m0gcvwxflr8xfsii081gmy7i-unixODBC-2.3.11/lib/libodbcinst.so.2 (0x00007f47a63ec000) libkrb5.so.3 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libkrb5.so.3 (0x00007f47a6312000) libgssapi_krb5.so.2 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libgssapi_krb5.so.2 (0x00007f47a62bd000) libstdc++.so.6 => /nix/store/7ls5xhx6kqpjgpg67kdd4pmbkhna4b6c-gcc-12.2.0-lib/lib/libstdc++.so.6 (0x00007f47a5bda000) libm.so.6 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libm.so.6 (0x00007f47a5afa000) libgcc_s.so.1 => /nix/store/7ls5xhx6kqpjgpg67kdd4pmbkhna4b6c-gcc-12.2.0-lib/lib/libgcc_s.so.1 (0x00007f47a629c000) libpthread.so.0 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libpthread.so.0 (0x00007f47a6297000) libc.so.6 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libc.so.6 (0x00007f47a5914000) libk5crypto.so.3 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libk5crypto.so.3 (0x00007f47a6266000) libcom_err.so.3 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libcom_err.so.3 (0x00007f47a625f000) libkrb5support.so.0 => /nix/store/1zy45clchypamqmqq63zcixns02fg2l9-libkrb5-1.20.1/lib/libkrb5support.so.0 (0x00007f47a6250000) libkeyutils.so.1 => /nix/store/yzqwq9gd0r62n97ab51qdsb3gg1vq7aa-keyutils-1.6.3-lib/lib/libkeyutils.so.1 (0x00007f47a6249000) libresolv.so.2 => /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib/libresolv.so.2 (0x00007f47a6234000) /nix/store/x33pcmpsiimxhip52mwxbb5y77dhmb21-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 (0x00007f47a6417000)
My next step will be to use wireshark to monitor the traffic and see if any packets are making it to the port from the program, but since it’s working from outside of docker, it’s my suspicion that the problem is within the packaged lib…
strace seems like overkill and it’s very noisy, so I wouldn’t know what to be looking for.
What other things could I try?