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 طالما أنها في جبال الألب.

إنه أحد الآثار الجانبية لاستخدام نظام تشغيل بدون كل العناصر الأساسية في الحاوية للأسف. ربما يمكنك استخدام صورة باستخدام دبيان؟ أو صورة جبال الألب تأتي مع libc؟

توجد واجهة برمجة التطبيقات هذه قبل 3.7 لتحل محل عدم وجود واجهة برمجة تطبيقات لها في بايثون. إن اكتشاف ما إذا كانت واجهة برمجة التطبيقات متاحة (للغة python> = 3.7) سيؤدي على الأقل إلى حل مشكلة هذه الإصدارات. قبل ذلك نحتاج إلى التحقق مما يمكن فعله.

إنه أحد الآثار الجانبية لاستخدام نظام تشغيل بدون كل العناصر الأساسية في الحاوية للأسف. ربما يمكنك استخدام صورة باستخدام دبيان؟ أو صورة جبال الألب تأتي مع libc؟

توجد واجهة برمجة التطبيقات هذه قبل 3.7 لتحل محل عدم وجود واجهة برمجة تطبيقات لها في بايثون. إن اكتشاف ما إذا كانت واجهة برمجة التطبيقات متاحة (للغة python> = 3.7) سيؤدي على الأقل إلى حل مشكلة هذه الإصدارات. قبل ذلك نحتاج إلى التحقق مما يمكن فعله.

يستخدم Alpine musl libc بدلاً من glibc كجزء من كونه قائمًا على BUSYBOX ، وبالطبع سيكون استخدام الصور الأساسية الأخرى حلاً بديلاً ولكنه سيحد من استخدامات gunicorn نظرًا لأن كلا من نظام التشغيل alpine ونظام التشغيل الأدنى الآخر الذي يزداد شعبيته (والتي غالبًا ما تكون قائمة تحتوي جميعها على \ Busybox \ etc) موسل بدلاً من glibc ، لذا من المحتمل ألا يقتصر التأثير على جبال الألب (فقط الأكثر شيوعًا المتأثر).

يبدو لي أن شيئًا ما مثل اكتشاف ما إذا تم تثبيت musl بدلاً من glibc وإذا كان الأمر كذلك ، فاستخدم أي حل موجود في 19.9.x هو إصلاح محتمل ليس إصدار Python محددًا كما نعلم أن 19.9.x يعمل جيدًا.

وجدت مشكلة ذات صلة في docker-library / python # 111

ربما يمكن إعادة استخدام هذا الرمز بطريقة: https://github.com/python/cpython/pull/10453/commits/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 ، التصحيح الذي ربطته أعلاه يقوم

aljinovic ممكن تجرب fda61b5479646f68faef30f3cb034ce16f3c61b6. يجب أن يصلح مشكلتك. دعني اعرف :)

لقد جربته ولم ينجح. لقد وجدت خطأ في التنفيذ الخاص بك ، إليك اقتراح الإصلاح:

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

hrm غريب ، هل يمكنك لصق لي الخطأ الذي كان لديك؟

شفرتك: 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

حسنًا ، لإصلاح ذلك ، لست متأكدًا من سبب عمل الكرة الأرضية nlot بالطريقة الأولى. أنا بحاجة للاختبار

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 صباحًا Ante Aljinovic [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=AAADRISHZX5Q265IJQ5OCKLQUZRMJA5CNFSM4JLJUUP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW43
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAADRIXWUCJLU6ZCD2R2Z6DQUZRMJANCNFSM4JLJUUPQ
.

رائع ، لقد نجح ذلك ، شكرًا لك!

عمل جيد للجميع!

هل يمكنك جميعًا اختبار # 2208 لأنني غيرت التنفيذ لاستخدام مكتبة Python القياسية. نرحب بأي ملاحظات :)