`test_socket` fails on systems without certain entries in `/etc/services`

Bug report

Bug description:

Description

I encountered a failure in test_socket.py on a minimal Linux environment. This issue appears due to the test suit's assumption about system configuration, not a bug in the socket module itself.

Environment

• OS: debian:bookworm-slim(Docker)
• Architecture: x86-64

Error log

======================================================================
ERROR: testGetServBy (test.test_socket.GeneralModuleTests.testGetServBy)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/src/Lib/test/test_socket.py", line 1279, in testGetServBy
    raise OSError
OSError

======================================================================
ERROR: testGetaddrinfo (test.test_socket.GeneralModuleTests.testGetaddrinfo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/src/Lib/test/test_socket.py", line 1676, in testGetaddrinfo
    socket.getaddrinfo(HOST, "http")
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
  File "/src/Lib/socket.py", line 992, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
               ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -8] Servname not supported for ai_socktype

Analysis

Though these two functions throw different types of exception, I believe both of them related to the test assume that some services have defined in /etc/services file. However, not all Linux distributions include these entries by default.

This problem stems from that test_socket.py rely on getaddrinfo() and getservbyname() systemcall, which will return services declared in /etc/services. test_socket.py didn't check if the systems has a /etc/services file or declare the services we need(daytime, qotd, domainfor testGetServBy and http for testGetaddrinfo), and the socket module will throw exceptions when the test try to get the information of an 'unknown' service, which fail the test.

Most of the Linux distributions declare common services and their ports in /etc/services, but there's no mandatory standards about which services should be included in /etc/services file. In this case, the test use hardcoding services name that not exist in some distributions and cause the error.

Reproduction

Use Docker

The issue can be reproduced using the following dockerfile.

FROM debian:bookworm-slim

ARG APT_SOURCE=deb.debian.org

RUN sed -i "s|deb.debian.org|${APT_SOURCE}|g" /etc/apt/sources.list.d/debian.sources && \
    apt-get update && \
    apt-get install -y --no-install-recommends \
    git vim pkg-config build-essential gdb lcov \
    libbz2-dev libffi-dev libgdbm-dev libgdbm-compat-dev liblzma-dev \
    libncurses5-dev libreadline6-dev libsqlite3-dev libssl-dev \
    lzma lzma-dev tk-dev uuid-dev zlib1g-dev libzstd-dev libnss3-dev && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

RUN useradd -m -U dev && \
    mkdir /src && chown dev:dev /src

USER dev
WORKDIR /src

CMD ["/bin/bash"]

Setup manually

Alternatively, we can modify the /etc/services file to reroduce this issue. Remove or comment out the lines containing daytime, qotd, domain and http or delete the /etc/services file entirely before running the test.

Fixing

I suggest modifying the test to skip if the required services are not available, or to query the /etc/services file for an available service.

I'd be happy to submit a patch if the core team agrees with this fix.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-138219

Comece em Lib/test/test_socket.py, em GeneralModuleTests.testGetServBy e testGetaddrinfo, e reproduza o problema deixando ausentes de /etc/services as entradas daytime, qotd, domain e http. Confirme que o tratamento escolhido evita falhas quando esses serviços não estão disponíveis e execute os testes de socket afetados; o PR vinculado gh-138219 indica que o trabalho pode já estar em andamento.