Gunicorn: Gunicorn 20.0.0: find_library ('c') не работает в Alpine Linux

Верно. Вероятно, мы должны проверить, если python = <3.7, чтобы использовать socket.from_fd в https://github.com/benoitc/gunicorn/blob/438371ee90b9676336a44c7abaeb30ee7fc57a5c/gunicorn/socketfromfd.py#L65

Во-первых, спасибо за отличную программу!
Во-вторых, я могу подтвердить эту проблему; это происходило при каждой установке 20.0.0 на Alpine.

Верно. Вероятно, нам следует проверить, если python = <3.7, чтобы использовать socket.from_fd в

https://github.com/benoitc/gunicorn/blob/438371ee90b9676336a44c7abaeb30ee7fc57a5c/gunicorn/socketfromfd.py#L65

Можно подтвердить, что проблема не связана с конкретной версией Python, происходит ли она в 3.6,3.7,3.8, если она находится в Alpine.

К сожалению, это побочный эффект использования операционной системы без всех базовых библиотек в контейнере. Может быть, вы могли бы использовать образ с помощью Debian? или образ alpine с libc?

Этот api существует до версии 3.7, чтобы заменить отсутствие API для него в Python. Обнаружение доступности api (для python> = 3.7), по крайней мере, решит проблему для этих версий. Перед этим нам нужно выяснить, что можно сделать.

К сожалению, это побочный эффект использования операционной системы без всех базовых библиотек в контейнере. Может быть, вы могли бы использовать образ с помощью Debian? или образ alpine с libc?

Этот api существует до версии 3.7, чтобы заменить отсутствие API для него в Python. Обнаружение доступности api (для python> = 3.7), по крайней мере, решит проблему для этих версий. Перед этим нам нужно выяснить, что можно сделать.

Alpine использует musl libc вместо glibc, поскольку часть его основана на busybox, конечно, использование других базовых образов было бы обходным путем, но это ограничит использование Gunicorn как alpine, так и других минимальных ОС, которые становятся все более популярными (которые часто основаны на на нем \ busybox \ etc) у всех есть musl вместо glibc, поэтому влияние, вероятно, не ограничивается alpine (затронут только самый популярный).

Мне кажется, что что-то вроде определения того, установлен ли musl вместо glibc, и если да, то использовать любое решение, которое было в 19.9.x, - это потенциальное исправление, которое не зависит от версии Python, поскольку, как мы знаем, 19.9.x работает хорошо.

обнаружил связанную проблему в docker-library / python # 111

возможно, этот код можно использовать повторно: https://github.com/python/cpython/pull/10453/commit/e3f67780aab24401a50af64e688d38c24ee41ad0

Для этого есть один возможный обходной путь, поскольку искаженные пользователи столкнулись с тем же:
https://stackoverflow.com/questions/48234723/twisted-server-monkey-patch-file
Этот фрагмент кода из gunicorn/socketfromfd.py можно переписать следующим образом:

_libc_name = find_library('c')
if _libc_name is None:
    _libc_name = 'libc.so.6'
libc = ctypes.CDLL(_libc_name, use_errno=True)

Одно из возможных решений, но, вероятно, не лучшее.

возможно, этот код можно повторно использовать следующим образом: python / cpython @ e3f6778

Я думаю, что это проблема: https://bugs.python.org/issue21622

Давайте найдем обходной путь и выпустим патч.

@tilgovi патч, который я свое дело (и он указан в сообщении об ошибке, которое вы добавили). Я буду работать над PR, который его использует.

@aljinovic, можешь попробовать fda61b5479646f68faef30f3cb034ce16f3c61b6. Это должно решить вашу проблему. Дайте мне знать :)

Я попробовал, но не работает. Я обнаружил ошибку в вашей реализации, вот предложение по исправлению:

for suffix in ['so', '*.so.*']:
    for f in glob('{0}.{1}'.format(prefix, suffix)):

хрм странно, ты можешь вставить мне ошибку, которая у тебя была?

Ваш код: find_library("c") возвращает None .
После моего изменения он возвращается: libc.musl-x86_64.so.1

Кроме того, мне пришлось сначала вручную установить LD_LIBRARY_PATH , так что, возможно, это может помочь:

paths = ['/lib', '/usr/local/lib', '/usr/lib']
if 'LD_LIBRARY_PATH' in os.environ:
    paths = os.environ['LD_LIBRARY_PATH'].split(':') + paths

Взято из:
https://github.com/alpinelinux/aports/blob/202f4bea916b0cf974b38ced96ab8fca0b192e3f/main/python2/musl-find_library.patch

Хорошо, исправляем это, но не уверен, почему глобус не работает первым способом. Мне нужно проверить

@aljinovic теперь должно быть в порядке, дайте мне знать

По-прежнему не работает, если я не перейду с:

for suffix in ['so', 'so.*']:

к:

for suffix in ['so', '*.so.*']:

Фактическое имя libc : libc.musl-x86_64.so.1

извините, я пропустил дополнительную звезду.
https://github.com/benoitc/gunicorn/commit/e150ca4ff87d52b1c2b3d5376fc71789b65a3fb4
должен исправить это сейчас.

В четверг, 21 ноября 2019 г., в 11:47 Анте Алжинович [email protected]
написал:

По-прежнему не работает, если я не перейду с:

для суффикса в ['so', 'so. *']:

к:

для суффикса в ['so', ' .so. ']:

Фактическое имя libc: libc.musl-x86_64.so.1

-
Вы получаете это, потому что изменили состояние открытия / закрытия.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/benoitc/gunicorn/issues/2160?email_source=notifications&email_token=AAADRISHZX5Q265IJQ5OCKLQUZRMJA5CNFSM4JLJUUP2YY3PNVWWK3TUL52HS4DFVREXG43
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AAADRIXWUCJLU6ZCD2R2Z6DQUZRMJANCNFSM4JLJUUPQ
.

Отлично, сработало, спасибо!

Всем отличной работы!

Можете ли вы все протестировать # 2208, поскольку я изменил реализацию, чтобы просто использовать стандартную библиотеку python. Любые отзывы приветствуются :)