Systemd-swap: مشاكل مع إضافة SystemCallFilters مؤخرًا على بعض الأنظمة المستندة إلى ARM

من المثير للاهتمام أن التغيير الذي أجريته لا يُصلح المشكلة الأساسية (مما يمكنني قوله) ، فهو يجعل الأمر فقط بحيث إذا نفذ SystemCallFilter systemd-swap شيئًا ليس في القائمة البيضاء SystemCallFilter فإنه أخطاء بدلاً من إنهاء معالجة.

سأكون مهتمًا برؤية استدعاء النظام الذي يسبب هذا الخطأ وإضافة ذلك إلى القائمة البيضاء.: التفكير:
يمكنك:

1. تحقق مما إذا كانت إزالة SystemCallArchitectures=native حل المشكلة؟
2. في السطر 3 في systemd-swap أضف x بحيث يقرأ set -xuo pipefail ثم حاول مرة أخرى؟ (وقدم سجلات كاملة (على الرغم من أنها قد تكون طويلة جدًا بحيث لا يمكن تحميلها في تعليق ، لذا قد ترغب في استخدام أداة لصق)).

لسوء الحظ ، أنا أملك فقط أجهزة x86 ، لذلك لا يمكنني اختبار ذلك بنفسي.

نعم ، هذا هو رأيي أيضًا. إضافة SystemCallErrorNumber = ستُرجع EPERM خطأ فقط ولن تنهي العملية على الفور. ربما ليست مثالية - فهمت.

لقد قمت بلصق ثلاثة اختبارات على Odroid-XU4 بعد تغيير السطر 3 في البرنامج النصي إلى set -xuo pipefail هنا: https://pastebin.com/UZk74aKx

الاختبار 1 - SystemCallArchitectures التي تمت إزالتها = أصلي. نفس الفشل / coredumps من الفرز و mkswap
الاختبار 2 - تم تشغيله باستخدام ملف systemd-swap.service غير معدل من systemd-swap 4.2.3. نفس الفشل / النوى.
الاختبار 3 - إعادة إضافة SystemCallErrorNumber = EPERM ... وبالطبع ، يعمل بشكل جيد.

يتم تضمين جميع الاختبارات الثلاثة في نفس علبة الباستيبين. ابحث في "اختبار" لتحديد موقع كل منها.

إذا كان هناك أي شيء آخر يمكنني اختباره أو تجربته ، يسعدني تقديم المساعدة.

هل يمكنك المحاولة باستخدام SystemCallFilter=@system-service <strong i="5">@swap</strong> <strong i="6">@module</strong> uname وكل شيء آخر غير معدل؟

وإذا أدى ذلك إلى حدوث عطل ، فيرجى تقديم تتبع مكدس لـ mkswap. يجب أن يظهر في المجلة مباشرة بعد الانهيار. بدلاً من ذلك ، يمكنك الحصول عليه عبر النواة الملغاة باستخدام gdb باستخدام شيء مثل gdb -c <dumped core> و thread apply all bt full .

يمكنك أيضًا محاولة الحصول على الحد الأدنى من النسخ باستخدام وحدة عابرة ، والتي قد تكون أكثر ملاءمة لتصحيح الأخطاء:

dd if=/dev/zero of=test count=32 bs=1M
sudo systemd-run -t -d -p Type=exec -p "SystemCallFilter=@system-service <strong i="13">@swap</strong> @module" -p SystemCallArchitectures=native mkswap test`

لم أستطع التكاثر على AArch64 / ARM64 ، ARMv8.

لسوء الحظ ، فإن إضافة uname إلى SystemCallFilter لا يزال ينتج عنه تفريغ. :( انظر أدناه لتتبع المكدس. لا توجد رموز للأسف.

FWIW ، أنا أقوم بتشغيل zswap_enabled = 0 و zram_enabled = 1 - ليس لدي قسم مبادلة فعلي لذلك أستخدم zram كمبادلة فقط.

لديّ Odroid-N2 أيضًا بتشغيل archlinuxarm وإعداده مطابق في الغالب لـ Odroid-XU4 و Pi3. لم أكن أستخدم systemd-swap على N2 بالرغم من ذلك. فقط لمعرفة ما سيحدث ، قمت بتثبيت systemd-swap مع ملف خدمة "stock" على N2. لقد عطلت zswap وقمت بتمكين zram تمامًا كما في XU4. يعمل بشكل جيد على N2 - لا نوى. إن N2 هو ARMv8 / aarch64. XU4 / Pi3 كلاهما ARMv7. مثلك ، لا يمكنني التكاثر على ARMv8 / aarch64 أيضًا.

يمكنني البحث عن بطاقة SD أخرى لـ Pi3 القديم وتجربة Raspbian (أو ؟؟؟) بدلاً من archlinuxarm عليها. ربما هذه مشكلة غريبة خاصة بـ archlinuxarm مع تصميمات ARMv7 الخاصة بهم؟

ما زلت سعيدًا لتجربة أي اقتراحات أخرى ... لكن أفهم تمامًا ما إذا كانت أفكارك قد نفدت.

Jul 01 20:20:59 xu4 systemd-swap[256]: /usr/bin/systemd-swap: line 52: 
   335 Bad system call         (core dumped) mkswap "${zram_dev}" &> /dev/null
Jul 01 20:20:59 xu4 systemd-swap[256]: + systemctl daemon-reload
Jul 01 20:21:00 xu4 systemd-coredump[338]: Process 335 (mkswap) of user 0 dumped core.

                                           Stack trace of thread 335:
                                           #0  0x00000000b6e04e58 posix_fadvise64 (libc.so.6 + 0xd2e58)


           PID: 335 (mkswap)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 31 (SYS)
     Timestamp: Wed 2020-07-01 20:20:59 MDT (18min ago)
  Command Line: mkswap /dev/zram0
    Executable: /usr/bin/mkswap
 Control Group: /system.slice/systemd-swap.service
          Unit: systemd-swap.service
         Slice: system.slice
       Boot ID: 734e377074d04e70a5da783259d3fb10
    Machine ID: b16181464c2c4ea7adb0a759515a8a9a
      Hostname: xu4
       Storage: /var/lib/systemd/coredump/core.mkswap.0.734e3770[...]00.lz4
       Message: Process 335 (mkswap) of user 0 dumped core.

                Stack trace of thread 335:
                #0  0x00000000b6e04e58 posix_fadvise64 (libc.so.6 + 0xd2e58)



Thread 1 (LWP 335):
#0  0xb6e04e58 in posix_fadvise64 () from /usr/lib/libc.so.6
No symbol table info available.
#1  0xb6e8fe68 in blkid_probe_set_device () from /usr/lib/libblkid.so.1
No symbol table info available.
#2  0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
quit

ربما هذه مشكلة غريبة خاصة بـ archlinuxarm مع تصميمات ARMv7 الخاصة بهم؟

قد يكون.

@system-service يجب أن تتضمن fadvise64 نظام استدعاء بالفعل، لذلك إذا لم تقم بتعديل المجموعات استدعاء نظام للسيستم دي وإزالته (انظر systemd-analyze syscall-filter @system-service )، فإنه لا ينبغي جعل أي اختلاف يحاول إدراجه في القائمة البيضاء ، ولكن يمكنك المحاولة إذا لم تكن قد قمت بذلك بالفعل.
هذا بالطبع على افتراض أنه دائمًا ما يتعطل في هذا النظام الدقيق.

نظرًا لأنه لا يبدو مرتبطًا بشكل مباشر بـ systemd-swap وبسبب وثائق النظام التي توصي فعليًا بإضافة SystemCallErrorNumber=EPERM ، يجب إضافته فقط إلى وحدة الخدمة في رأيي.

سيكون منتفخًا إذا كان بإمكانك الحصول على علامات تصحيح الأخطاء ونشر coredump هنا حتى نتمكن من معرفة الوظيفة الموجودة في mkswap تسبب الخطأ.

ما زلت متحيزًا إلى الحل الأصلي المتمثل في إضافة SystemCallErrorNumber=EPERM - hahaha. لذلك أنا سعيد لأنك مضيت قدمًا وفعلت ذلك. مقدر جدا! يوفر لي تجاوز خدمة systemd لإصدار مستقبلي. 👍

أنا أيضًا أشعر بالفضول إلى حد ما حول سبب إغراقها في أجهزة ARMv7. ليس فقط mkswap ، ولكن أيضًا sort و blkid . سأحصل على زوج من ARMv7 R-Pis القديم وأقوم بتثبيتات جديدة / حالية لـ ArchlinuxARM و Raspian / Debian. سيتم اختبار كلاهما باستخدام systemd-swap ومعرفة ما إذا كانت المشكلة تحدث في كلا نظامي التشغيل. سوف أرى ما إذا كان بإمكاني الحصول على المزيد من مقالب سمين.

على الرغم من عدم وجود رموز تصحيح أخطاء ، ما زلنا نعرف الوظائف التي تم استدعاؤها قبل الانهيار بسبب جداول الرموز الديناميكية.

mkswap calls blkid_probe_set_device الذي يستدعي posix_fadvise (غلاف رفيع حول مكالمة syscall) لتعطيل القراءة المسبقة التي يتم إجراؤها بواسطة kernel.

وبقدر ما أعلم ، تستخدم جميع الأدوات المساعدة المعطلة المذكورة fadvise64 syscall بطريقة أو بأخرى.

لا يزال لدي بعض الأسئلة التي يمكن الإجابة عليها بدون رموز تصحيح الأخطاء / تثبيت جديد:

• أود أن أرى بعض آثار المكدس الأخرى لـ mkswap (هل هو مشابه؟) ، sort و blkid .
• وهل يصطدمون بكل الدعاء؟
• ما هي نتيجة استدعاءهم بشكل مستقل مع الوحدة المؤقتة كما هو مذكور في رسالتي السابقة؟
• هل يساعد إدراج fadvise64 القائمة البيضاء؟

نعم ، يتعطل mkswap و sort و blkid كل مرة - دائمًا مع تتبع المكدس الذي يشير إلى posix_fadvise64 . يحدث الشيء نفسه مع اختبار الوحدة العابرة mkswap.

لقد تحققت من أن fadvise64 (و fadvise64_64) كلاهما موجودان في قائمة مرشح النظام الافتراضي @system-service systemd. التبييض لا فرق. :(

أجرى أيضًا اختبارًا سريعًا على تثبيت Raspbian جديد بنفس النتائج ... لذا يبدو أنه ليس مشكلة خاصة بـ ArchlinuxARM.

تشغيل strace mkswap temp خارج systemd وأي مرشحات syscall لا تظهر أي مشكلة - كما تتوقع:

fadvise64_64(3, 0, 0, POSIX_FADV_RANDOM) = 0

تشغيل strace mkswap temp عبر systemd (تم تعديل وحدتك العابرة - فكرة رائعة!) مع @system-service <strong i="19">@swap</strong> <strong i="20">@module</strong> @debug جميع القوائم البيضاء تظهر systemd العملية مباشرة عند استدعاء fadvise64_64:

fadvise64_64(3, 0, 0, POSIX_FADV_RANDOM) = ?
+++ killed by SIGSYS (core dumped) +++

أنا على حق في نهاية معرفتي / قدرتي في معرفة ما يحدث. 😄

شكرا.

هذا يبدو وكأنه بعض غرابة systemd / seccomp على ARMv7.

إذا سمحت لـ systemd بتثبيت عامل تصفية seccomp لمكالمة syscall غير ذات صلة (على سبيل المثال ، شيء من @قديم أو @التصحيح عبر القائمة السوداء مثل SystemCallFilter=~ptrace ) ، هل يتعطل؟

بصرف النظر عن ذلك ، لا أعرف أي طريقة أخرى لتصحيح هذا الأمر دون الخوض في تفاصيل مطولة. أعتقد أن أفضل مسار للعمل سيكون إبلاغ مشرف / مطوري النظام بهذا الأمر.

لا يزال وضع شيء غير مرتبط في القائمة السوداء يتسبب في حدوث عطل ما لم تتم إضافة SystemCallErrorNumber=EPERM أيضًا إلى الخدمة.

... ولكن كما ذكرت ، يبدو أن هذه مشكلة غريبة في systemd / seccomp مع ARMv7.

كاختبار آخر لفضولي ، قمت بتحرير systemd-swap.service باستخدام إعدادات SystemCall * هذه:

SystemCallArchitectures=native
SystemCallFilter=@system-service <strong i="10">@swap</strong> <strong i="11">@module</strong>
SystemCallFilter=~finit_module
SystemCallErrorNumber=EPERM

لقد قمت على وجه التحديد بإدراج finit_module القائمة السوداء - لذلك لا يمكن تحميل الوحدة النمطية zram .

على Odroid-N2 (aarch64) الذي يعمل بنظام ArchlinuxARM w / systemd 245.6 ، فإنه يفشل كما تتوقع - لا يمكن تحميل وحدة zram . مع أو بدون SystemCallErrorNumber=EPERM كل شيء يبدو أنه يعمل بشكل طبيعي على N2 / aarch64 & seccomp.

Jul 02 19:08:26 n2 systemd[1]: Starting Manage swap spaces on zram, files and partitions....
Jul 02 19:08:27 n2 systemd-swap[3924]: INFO: Load: /etc/systemd/swap.conf
Jul 02 19:08:27 n2 systemd-swap[3924]: WARN: Combining zram with zswap/swapfc/swapd_auto_swapon [...]
Jul 02 19:08:27 n2 systemd-swap[3924]: INFO: Zram: check availability
Jul 02 19:08:27 n2 systemd-swap[3924]: INFO: Zram: not part of kernel, trying to find zram module
Jul 02 19:08:27 n2 systemd-swap[3963]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:27 n2 systemd[1]: Started Manage swap spaces on zram, files and partitions..
Jul 02 19:08:28 n2 systemd-swap[4040]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:29 n2 systemd-swap[4042]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:30 n2 systemd-swap[4043]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:31 n2 systemd-swap[4044]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:49 n2 systemd-swap[4052]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:50 n2 systemd-swap[4053]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:51 n2 systemd-swap[4054]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:52 n2 systemd-swap[4056]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:53 n2 systemd-swap[4057]: modprobe: ERROR: could not insert 'zram': Operation not permitted
Jul 02 19:08:54 n2 systemd-swap[3924]: INFO: Zram: module successfully loaded
Jul 02 19:08:54 n2 systemd-swap[3924]: INFO: Zram: trying to initialize free device
Jul 02 19:08:54 n2 systemd-swap[3924]: WARN: Zram: zramctl can't find free device
Jul 02 19:08:54 n2 systemd-swap[3924]: INFO: Zram: using workaround hook for hot add
Jul 02 19:08:54 n2 systemd-swap[3924]: ERRO: Zram: this kernel does not support hot adding zram devices [...]
Jul 02 19:08:54 n2 systemd[1]: systemd-swap.service: Main process exited, code=exited, status=1/FAILURE
Jul 02 19:08:54 n2 systemd[1]: systemd-swap.service: Failed with result 'exit-code'.

على Pi2 القديمة (armv7l) التي تعمل أيضًا بنظام ArchlinuxARM w / systemd 245.6 ، فإنها لا تفشل! لا يتم تحميل الوحدة النمطية zram أي مشكلة على الرغم من عدم إمكانية ذلك بسبب القائمة السوداء.

Jul 02 19:14:07 alarmpi systemd[1]: Starting Manage swap spaces on zram, files and partitions....
Jul 02 19:14:08 alarmpi systemd-swap[299]: INFO: Load: /etc/systemd/swap.conf
Jul 02 19:14:08 alarmpi systemd[1]: Started Manage swap spaces on zram, files and partitions..
Jul 02 19:14:08 alarmpi systemd-swap[299]: WARN: Combining zram with zswap/swapfc/swapd_auto_swapon [...]
Jul 02 19:14:08 alarmpi systemd-swap[299]: INFO: Zram: check availability
Jul 02 19:14:08 alarmpi systemd-swap[299]: INFO: Zram: not part of kernel, trying to find zram module
Jul 02 19:14:09 alarmpi systemd-swap[299]: INFO: Zram: module successfully loaded
Jul 02 19:14:10 alarmpi systemd-swap[299]: INFO: Zram: trying to initialize free device
Jul 02 19:14:10 alarmpi systemd-swap[299]: INFO: Zram: initialized: /dev/zram0
Jul 02 19:14:12 alarmpi systemd-swap[299]: INFO: Zram: trying to initialize free device
Jul 02 19:14:13 alarmpi systemd-swap[299]: INFO: Zram: initialized: /dev/zram0
Jul 02 19:14:14 alarmpi systemd-swap[299]: INFO: Zram: trying to initialize free device
Jul 02 19:14:14 alarmpi systemd-swap[299]: INFO: Zram: initialized: /dev/zram1
Jul 02 19:14:16 alarmpi systemd-swap[299]: INFO: Zram: trying to initialize free device
Jul 02 19:14:16 alarmpi systemd-swap[299]: INFO: Zram: initialized: /dev/zram2
Jul 02 19:14:17 alarmpi systemd-swap[299]: INFO: swapD: pickup devices from systemd-gpt-auto-generator
Jul 02 19:14:17 alarmpi systemd-swap[299]: INFO: swapD: searching swap devices

تبدو مثل SystemCallFilter / الاشياء seccomp مكسورة / تجاهل على الجهاز armv7l ... وcoredumps بالتأكيد ما لم SystemCallErrorNumber=EPERM تم تكوينه أيضا في الملف. الخدمة. اختبار قصير جدًا باستخدام نفس Pi2 و Raspbian (مقابل ArchlinuxARM) يعرض نفس المشكلة. على Odroid-XU4 (armv7l أيضًا) - نفس المشكلة.

لذلك أقدر أنك تضيف SystemCallErrorNumber=EPERM لأنه لا يبدو أنه يسبب أي مشاكل على الأنظمة الأساسية الأخرى ويصلح بطريقة سحرية موقفًا سيئًا على armv7l. 👍 سأفعل المزيد من البحث في Googling / القراءة / الاختبار. إذا كان بإمكاني كتابة شيء لا يبدو سخيفًا مع بعض الأدلة و / أو الأدلة ، فقد أرسل مشكلة مع أعضاء النظام لمعرفة ما قد يقترحونه. 😄

نقدر مساعدتك وصبرك! شكرا لك.

لا يزال وضع شيء غير مرتبط في القائمة السوداء يتسبب في حدوث عطل ما لم تتم إضافة SystemCallErrorNumber=EPERM أيضًا إلى الخدمة.

... ولكن كما ذكرت ، يبدو أن هذه مشكلة غريبة في systemd / seccomp مع ARMv7.

نعم ، هذا ما كنت أحاول اختباره من خلال وضع قائمة سوداء لمكالمة غير ذات صلة فقط ، دون تصفية أي شيء آخر.

SystemCallErrorNumber=EPERM بإرجاع EPERM للعملية المسيئة بدلاً من إرسال SIGSYS وإغراق النواة نتيجة لذلك.

أعتقد أن هذا قد يقدم بعض السلوك غير المحدد إذا كانت العملية تعتمد على syscall لتعمل ولا تتحقق من النجاح. لذا أود أن أسمي هذا حلاً ، وليس حلاً.

قد تكون الخطوة التالية هي تمكين تصحيح أخطاء النظام لأن اختبار القائمة السوداء يوضح أن هناك شيئًا ما معطلاً.

https://freedesktop.org/wiki/Software/systemd/Debugging/

حظا طيبا وفقك الله.

أعتقد أنه يتم إغلاق هذا باعتباره خطأ ArchlinuxARM؟ هل يؤثر على التوزيعات الأخرى أيضًا؟

يجب أن تؤثر على منصات ARM بغض النظر عن التوزيعات.

هل هو شيء من الأجهزة أم شيء من لينكس؟

الشيء في نظام Linux ، المشكلة هي أن تقوية الخدمة لدينا تعتمد على القائمة البيضاء لنظام systemd والتي تم تكوينها بشكل خاطئ لبعض عمليات syscalls ARM ، لذلك على الرغم من أنه يجب السماح بعمليات syscalls ، إلا أنها ليست كذلك.