# Socket.socket().setsockopt() incompatibility with Alpine Linux (and musl libc) **URL:** \ **Category:** Python Help\ **Created:** [July 3, 2024, 7:27pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289 "2024-07-03T19:27:15Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![mcepl](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mcepl/32/24095_2.png) [@mcepl](https://discuss.python.org/u/mcepl)\ **Post date:** [July 3, 2024, 7:27pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/1 "2024-07-03T19:27:16Z")
(also on [Socket.socket().setsockopt() incompatibility with Alpine Linux (and musl libc) — sourcehut lists](https://lists.sr.ht/~mcepl/m2crypto/%3CD2G5MSVNL9PI.13VP1KFTOJE9Y@cepl.eu%3E)) I know that two of the three most suspicious statements it is a fault of interpreter, and it is a fault of `libc`, but I am slowly sliding towards this. When investigating [problems with time representation on 32bit platforms](https://todo.sr.ht/~mcepl/m2crypto/341), I run the test suite of [M2Crypto](https://sr.ht/~mcepl/m2crypto) in `i386/alpine` and I found problems with `socket.setsockopt` call. When running the code distilled into this short script, I found some problems: ```python import socket import struct from M2Crypto import SSL ctx = SSL.Context() s = SSL.Connection(ctx) timeout = SSL.timeout() print(f"timeout.sec = {timeout.sec}") print(f"timeout.microsec = {timeout.microsec}") print(f"timeout.pack() = {timeout.pack()}") print(f"socket.SOL_SOCKET = {socket.SOL_SOCKET}") print(f"socket.SO_RCVTIMEO = {socket.SO_RCVTIMEO}") s.socket.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO, timeout.pack()) ``` When running on [i386/debian](https://gitlab.com/m2crypto/m2crypto/-/jobs/7259144459) there is no problem and the script outputs: ```python $ python3 small_test.py timeout.sec = 600 timeout.microsec = 0 timeout.pack() = b'X\x02\x00\x00\x00\x00\x00\x00' socket.SOL_SOCKET = 1 socket.SO_RCVTIMEO = 20 $ ``` while when it is run [i386/alpine](https://gitlab.com/m2crypto/m2crypto/-/jobs/7259144424) it fails: ```python $ python3 small_test.py Traceback (most recent call last): File "/builds/m2crypto/m2crypto/small_test.py", line 14, in s.socket.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO, timeout.pack()) timeout.sec = 600 timeout.microsec = 0 timeout.pack() = b'X\x02\x00\x00\x00\x00\x00\x00' socket.SOL_SOCKET = 1 socket.SO_RCVTIMEO = 66 OSError: [Errno 22] Invalid argument $ ``` When studying the problem, I found [this comment](https://github.com/python/cpython/issues/74747#issuecomment-1093750153) by @tiran: > SO\_RCVTIME0 works only with operating system level sockets. A SSLSocket is not an OS level. It’s a high level abstraction layer that wraps either a file descriptor or a memory BIO. A read operation on a SSLSocket can perform write, a write operation can perform read. For the initial handshake, it will do both. > > This means that SO\_RCVTIME0 is not supported. Either you have to use the SSLSocket’s timeout feature or do your own socket io and use a memory BIO. The internal timeout feature is build around select()/poll() syscall and low level OpenSSL calls. Is this relevant here? `s.socket` is not `SSLSocket` or anything like that, but if I understand correctly it is just the plain `socket.socket` underlying all those complicated BIO constructs, isn’t it? ---
**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\ **Post date:** [July 3, 2024, 8:01pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/2 "2024-07-03T20:01:17Z")
Is `s.socket` an OS socket? What is its repr()? If you use the OS socket layer do you still see the issue or only via the SSL wrapper? Can you reproduce the issue using only the stdlib socket module? Maybe this is not a python issue by a kernel/libc issue. Can you reproduce the issue with a C program that does the same calls? ---
**Author:** ![mcepl](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mcepl/32/24095_2.png) [@mcepl](https://discuss.python.org/u/mcepl)\ **Post date:** [July 4, 2024, 9:13pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/3 "2024-07-04T21:13:57Z")
Yes, [the repr in the log](https://gitlab.com/m2crypto/m2crypto/-/jobs/7269384967#L910) is ```python s.socket = ``` ---
**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\ **Post date:** [July 4, 2024, 9:33pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/4 "2024-07-04T21:33:33Z")
Thanks for the repr. Given that my guess is you are looking at a C runtime or kernel issue. ---
**Author:** ![mcepl](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mcepl/32/24095_2.png) [@mcepl](https://discuss.python.org/u/mcepl)\ **Post date:** [July 4, 2024, 9:59pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/5 "2024-07-04T21:59:27Z")
I know that “It is a `libc` bug!” is the most common wrong suspicion in history of all suspicions, but it truly seems we could have it here. Thank you for making me a sound desk! ---
**Author:** ![cameron](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cameron/32/2658_2.png) [@cameron](https://discuss.python.org/u/cameron)\ **Post date:** [July 5, 2024, 12:07am UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/6 "2024-07-05T00:07:33Z")
This is low level enough that doing the same things in C would be pretty easy. See if you get `EINVAL` there also. socket() is a system call and so is setsockopt(), so aside from the shims in libc you should be looking at pretty direct “what does the kernel do?” stuff. ---
**Author:** ![tiran](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tiran/32/48_2.png) [@tiran](https://discuss.python.org/u/tiran)\ **Post date:** [July 5, 2024, 7:02pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/7 "2024-07-05T19:02:44Z")
FWIW, [PEP 11](https://peps.python.org/pep-0011/) does not list your platform as supported by Python upstream. Neither Linux on i686 / x86 nor Linux with musl libc are supported. Therefore any bug is between you and your vendor. I suggest that you file a bug with Alpine instead. One reason for the lack of musl libc support is the fact, that CPython’s regression test suite does not pass on Alpine – and never has. For years, the Alpine Python package [disables tests](https://git.alpinelinux.org/aports/tree/main/python3/APKBUILD#n151) like `test_os` instead of adressing the problem. ---
**Author:** ![mcepl](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mcepl/32/24095_2.png) [@mcepl](https://discuss.python.org/u/mcepl)\ **Post date:** [July 7, 2024, 7:44pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/8 "2024-07-07T19:44:15Z")
Ugh, that’s terrible. I have started with really high opinion about Alpine (and with recommendations of people like Drew DeVault) and more I learn about it, more I am disillusioned. Sad. ---
**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\ **Post date:** [July 7, 2024, 9:37pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/9 "2024-07-07T21:37:48Z")
> [@mcepl](#): > > really high opinion about Alpine Seems, from the use of musl and busybox, Alpine is aimed at embedded applications. Is that what you had in mind for it? If not you are better off with a fully featured linux distro. ---
**Author:** ![tiran](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tiran/32/48_2.png) [@tiran](https://discuss.python.org/u/tiran)\ **Post date:** [July 8, 2024, 7:22am UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/10 "2024-07-08T07:22:22Z")
Alpine is also popular for container images (Docker, podman), because the images are slightly smaller than Debian or UBI-based images. The problem with musl is that it’s not as well tested as glibc. The locale problem in `test_re` is easy to detect. Other bugs are more subtle, e.g. when Kerberos/GSSAPI authentication suddenly fails because the DNS SRV records got a bit longer and musl’s code for `edns0` with SRV does something wrong. ---
**Author:** ![mcepl](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mcepl/32/24095_2.png) [@mcepl](https://discuss.python.org/u/mcepl)\ **Post date:** [July 8, 2024, 1:14pm UTC](https://discuss.python.org/t/socket-socket-setsockopt-incompatibility-with-alpine-linux-and-musl-libc/57289/11 "2024-07-08T13:14:08Z")
I am developing [M2Crypto](https://sr.ht/~mcepl/m2crypto/), which is supposed to be a universal library working on all operating systems (including Windows, Mac OS X, \*BSD and similar stuff), so of course it includes all Linux distributions. My reaction at this moment is that I skip this test, and if anybody using Alpine files a bug about it, I will work on some platform specific solution.