Systemd-swap: कुछ एआरएम-आधारित सिस्टमों पर हाल ही में SystemCallFilters को जोड़ने की समस्याएं

दिलचस्प है, आपका परिवर्तन वास्तव में अंतर्निहित मुद्दे को ठीक नहीं करता है (जो मैं बता सकता हूं), यह केवल इतना बनाता है कि यदि systemd-swap SystemCallFilter श्वेतसूची पर कुछ निष्पादित नहीं करता है तो इसे समाप्त करने के बजाय त्रुटियां होती हैं प्रक्रिया।

मुझे यह देखने में दिलचस्पी होगी कि कौन सी सिस्टम कॉल इस त्रुटि का कारण बनती है और इसे श्वेतसूची में जोड़ें: सोच:
क्या तुम:

1. देखें कि क्या SystemCallArchitectures=native को हटाने से समस्या ठीक हो जाती है?
2. लाइन ३ पर systemd-swap में एक x ताकि वह set -xuo pipefail पढ़े और फिर पुनः प्रयास करें? (और पूर्ण लॉग दें (हालांकि वे एक टिप्पणी में अपलोड करने के लिए बहुत लंबे हो सकते हैं ताकि आप पेस्टबिन का उपयोग करना चाहें))।

दुर्भाग्य से मेरे पास केवल x86 हार्डवेयर है, इसलिए मैं स्वयं इसका परीक्षण करने में असमर्थ हूं।

हाँ, यह मेरा भी मत है। SystemCallErrorNumber=EPERM का जोड़ केवल एक त्रुटि लौटाएगा और प्रक्रिया को तुरंत समाप्त नहीं करेगा। शायद आदर्श नहीं - मैं समझता हूँ।

स्क्रिप्ट में लाइन 3 को set -xuo pipefail में बदलने के बाद मैंने Odroid-XU4 पर तीन परीक्षण किए: https://pastebin.com/UZk74aKx

टेस्ट 1 - हटा दिया गया SystemCallarchitecture=native. सॉर्ट और mkswap . से समान विफलता/कोरडम्प्स
टेस्ट २ - सिस्टमड-स्वैप ४.२.३ से एक गैर-संशोधित systemd-swap.service फ़ाइल के साथ चला। वही विफलता/कोरडंप।
टेस्ट 3 - SystemCallErrorNumber=EPERM को फिर से जोड़ा गया... और निश्चित रूप से, ठीक काम करता है।

सभी 3 परीक्षण एक ही पास्टबिन में शामिल हैं। प्रत्येक का पता लगाने के लिए "परीक्षण" पर खोजें।

अगर कुछ और है जिसका मैं परीक्षण कर सकता हूं या कोशिश कर सकता हूं, तो मुझे सहायता करने में खुशी होगी।

क्या आप SystemCallFilter=@system-service <strong i="5">@swap</strong> <strong i="6">@module</strong> uname साथ कोशिश कर सकते हैं और बाकी सब कुछ अपरिवर्तित है?

और अगर इससे कोई दुर्घटना होती है, तो कृपया mkswap का स्टैक ट्रेस प्रदान करें। यह दुर्घटना के ठीक बाद जर्नल में दिखाई देना चाहिए। वैकल्पिक रूप से आप इसे 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 के समान है। मैं हालांकि N2 पर सिस्टमड-स्वैप का उपयोग नहीं कर रहा था। बस यह देखने के लिए कि क्या होता है, मैंने N2 पर "स्टॉक" सेवा फ़ाइल के साथ सिस्टमड-स्वैप स्थापित किया। मैंने zswap को निष्क्रिय कर दिया और zram को XU4 की तरह ही सक्षम कर दिया। N2 पर ठीक चलता है - कोई कोरडंप नहीं। N2 ARMv8/aarch64 है। XU4/Pi3 दोनों ARMv7 हैं। आपकी तरह, मैं भी ARMv8/aarch64 पर पुन: पेश नहीं कर सकता।

मैं पुराने Pi3 के लिए एक और एसडी कार्ड खोद सकता हूं और उस पर आर्कलिनक्सर्म के बजाय रास्पियन (या ???) का प्रयास कर सकता हूं। हो सकता है कि यह उनके 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

हो सकता है कि यह उनके ARMv7 बिल्ड के साथ कुछ अजीब आर्कलिनक्सर्म विशिष्ट मुद्दा हो?

यह हो सकता है।

@system-service में पहले से ही fadvise64 सिस्टम कॉल शामिल होना चाहिए, इसलिए यदि उन्होंने सिस्टम कॉल समूहों को सिस्टमड के लिए संशोधित नहीं किया और इसे हटा दिया (देखें systemd-analyze syscall-filter @system-service ) , तो यह नहीं होना चाहिए कोई अंतर इसे श्वेतसूची में डालने का प्रयास कर रहा है, लेकिन आप कोशिश कर सकते हैं यदि आपने पहले से नहीं किया है।
यह निश्चित रूप से माना जाता है कि यह हमेशा उस सटीक सिस्कल पर दुर्घटनाग्रस्त हो जाता है।

चूंकि यह सीधे systemd-swap से संबंधित नहीं लगता है और सिस्टमड प्रलेखन के कारण वास्तव में SystemCallErrorNumber=EPERM जोड़ने की सिफारिश की गई है, इसे मेरी राय में सेवा इकाई में जोड़ा जाना चाहिए।

यह प्रफुल्लित होगा यदि आप डिबग फ़्लैग प्राप्त कर सकते हैं और यहां कोरडम्प पोस्ट कर सकते हैं ताकि हम देख सकें कि mkswap में कौन सा फ़ंक्शन त्रुटि का कारण बनता है।

मैं अभी भी SystemCallErrorNumber=EPERM - हाहाहा जोड़ने के मूल समाधान के लिए आंशिक हूं। इसलिए मुझे खुशी है कि आपने आगे बढ़कर ऐसा किया है। बहुत सराहना की! मुझे भविष्य में रिलीज के लिए एक सिस्टमड सेवा ओवरराइड बचाता है। मैं

मैं कुछ हद तक इस बारे में भी उत्सुक हूं कि एआरएमवी7 उपकरणों पर इसकी कोरडंपिंग क्यों है। यह न केवल mkswap , बल्कि यह sort और blkid । मैं पुराने ARMv7 R-Pis की एक जोड़ी को हथियाने जा रहा हूँ और ArchlinuxARM और रास्पियन/डेबियन की ताज़ा/वर्तमान स्थापनाएँ करूँगा। दोनों systemd-swap साथ परीक्षण करेंगे और देखेंगे कि क्या समस्या दोनों OSes में होती है। देखूंगा कि क्या मुझे और अधिक मांसल डंप मिल सकते हैं।

जबकि डिबग प्रतीक मौजूद नहीं हैं, हम अभी भी जानते हैं कि गतिशील प्रतीक तालिकाओं के कारण क्रैश से पहले किन कार्यों को बुलाया गया था।

mkswap कॉल blkid_probe_set_device जो कर्नेल द्वारा निष्पादित रीड-फ़ॉरवर्ड को अक्षम करने के लिए posix_fadvise (syscall के चारों ओर एक पतला आवरण) को कॉल करता है।

और जहां तक ​​​​मुझे पता है, सभी उल्लिखित क्रैशिंग यूटिलिटीज fadvise64 syscall का एक या दूसरे तरीके से उपयोग करती हैं।

मेरे पास अभी भी कुछ प्रश्न हैं जिनका उत्तर डिबग प्रतीकों/एक ताजा इंस्टॉल के बिना दिया जा सकता है:

• मैं mkswap (क्या यह समान है?), sort और blkid कुछ अन्य स्टैक ट्रेस देखना चाहता हूं।
• क्या वे सभी आमंत्रणों पर दुर्घटनाग्रस्त हो जाते हैं?
• जैसा कि मेरी पिछली पोस्ट में बताया गया है, उन्हें क्षणिक इकाई के साथ स्टैंडअलोन लागू करने का परिणाम क्या है?
• क्या fadvise64 को श्वेतसूची में डालने से मदद मिलती है?

हां, mkswap , sort , और blkid हर बार क्रैश - हमेशा posix_fadvise64 ओर इशारा करते हुए एक स्टैक ट्रेस के साथ। ऐसा ही mkswap क्षणिक इकाई परीक्षण के साथ होता है।

मैंने सत्यापित किया कि fadvise64 (और fadvise64_64) दोनों डिफ़ॉल्ट @system-service systemd syscall फ़िल्टर सूची में हैं। इसे श्वेतसूची में डालने से कोई फर्क नहीं पड़ता। :(

एक ही परिणाम के साथ एक ताजा रास्पियन इंस्टॉल पर एक त्वरित परीक्षण भी किया ... ऐसा लगता है कि यह एक आर्कलिनक्सएआरएम विशिष्ट मुद्दा नहीं है।

सिस्टमड के बाहर strace mkswap temp चलाना और कोई भी 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 सभी श्वेतसूची वाले शो सिस्टमड को fadvise64_64 कॉल पर प्रक्रिया को ठीक करते हैं:

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

क्या हो रहा है यह पता लगाने में मैं अपने ज्ञान/क्षमता के अंतिम छोर पर हूं। मैं

धन्यवाद।

यह ARMv7 पर कुछ systemd/seccomp अजीबता की तरह लगता है।

यदि आप सिस्टमड को एक असंबंधित syscall के लिए एक seccomp फ़िल्टर स्थापित करने देते हैं (उदाहरण के लिए @ से कुछअप्रचलित या @SystemCallFilter=~ptrace जैसे ब्लैकलिस्टिंग के माध्यम से डीबग करें), क्या यह क्रैश हो जाता है?

इसके अलावा, मुझे लंबे विवरण में जाने के बिना इसे और डीबग करने का कोई अन्य तरीका नहीं पता है। मुझे लगता है कि कार्रवाई का सबसे अच्छा तरीका यह होगा कि इसे सिस्टमड मेंटेनर/देवों को रिपोर्ट किया जाए।

जब तक SystemCallErrorNumber=EPERM को भी सेवा में नहीं जोड़ा जाता है, तब तक असंबंधित किसी चीज़ को ब्लैकलिस्ट करने से क्रैश हो जाता है।

लेकिन जैसा कि आपने उल्लेख किया है, यह ARMv7 के साथ कुछ अजीब systemd/seccomp समस्या प्रतीत होता है।

अपनी जिज्ञासा के लिए एक और परीक्षण के रूप में, मैंने इन SystemCall* सेटिंग्स के साथ systemd-swap.service संपादित किया:

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

ऐसा लगता है कि armv7l डिवाइस पर SystemCallFilter/seccomp सामान टूटा हुआ/अनदेखा है... और यह निश्चित रूप से coredumps है जब तक कि SystemCallErrorNumber=EPERM भी .service फ़ाइल में कॉन्फ़िगर नहीं किया जाता है। एक ही Pi2 और रास्पियन (बनाम ArchlinuxARM) का उपयोग करके बहुत संक्षिप्त परीक्षण एक ही समस्या प्रदर्शित करता है। एक Odroid-XU4 (armv7l भी) पर - एक ही समस्या।

इसलिए मैं सराहना करता हूं कि आप SystemCallErrorNumber=EPERM जोड़ रहे हैं क्योंकि ऐसा लगता है कि अन्य प्लेटफॉर्म पर कोई समस्या नहीं आती है और armv7l पर बुरी तरह से टूटी हुई स्थिति को जादुई रूप से ठीक करता है। 👍 मैं थोड़ा और गुगलिंग/पढ़ना/परीक्षण करूंगा। अगर मैं कुछ ऐसा लिख ​​सकता हूं जो कुछ सबूत और/या सबूत के साथ हास्यास्पद नहीं लगता है, तो मैं सिस्टमड लोगों के साथ एक समस्या प्रस्तुत कर सकता हूं यह देखने के लिए कि वे क्या सुझाव दे सकते हैं। मैं

आपकी मदद और धैर्य की सराहना करें! धन्यवाद।

जब तक SystemCallErrorNumber=EPERM को भी सेवा में नहीं जोड़ा जाता है, तब तक असंबंधित किसी चीज़ को ब्लैकलिस्ट करने से क्रैश हो जाता है।

लेकिन जैसा कि आपने उल्लेख किया है, यह ARMv7 के साथ कुछ अजीब systemd/seccomp समस्या प्रतीत होता है।

हां, यही वह है जो मैं किसी अन्य चीज़ को फ़िल्टर किए बिना केवल एक असंबंधित कॉल को ब्लैकलिस्ट करने के साथ परीक्षण करने का प्रयास कर रहा था।

SystemCallErrorNumber=EPERM सिर्फ रिटर्न EPERM बजाय भेजने की अपमानजनक प्रक्रिया के लिए SIGSYS और एक परिणाम के रूप में कोर डंपिंग।

मुझे लगता है कि यह कुछ अपरिभाषित व्यवहार पेश कर सकता है यदि प्रक्रिया कार्य करने के लिए सिस्कल पर निर्भर करती है और सफलता की जांच नहीं करती है। तो मैं इसे समाधान नहीं, समाधान कहूंगा।

अगला कदम सिस्टमड डिबगिंग को सक्षम करना हो सकता है क्योंकि आपके ब्लैकलिस्ट परीक्षण से पता चलता है कि कुछ बंद है।

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

आपको कामयाबी मिले।

मुझे लगता है कि इसे आर्कलिनक्सएआरएम बग के रूप में बंद किया जा रहा है? क्या यह अन्य डिस्ट्रोस को भी प्रभावित करता है?

डिस्ट्रो की परवाह किए बिना एआरएम प्लेटफॉर्म को प्रभावित करना चाहिए।

क्या यह एक हार्डवेयर चीज या एक लिनक्स चीज है?

लिनक्स की बात, समस्या यह है कि हमारी सेवा सख्त होना सिस्टमड की श्वेतसूची पर निर्भर करता है जो कुछ एआरएम सिस्को के लिए गलत कॉन्फ़िगर किया गया है, इसलिए हालांकि सिस्को को अनुमति दी जानी चाहिए, वे नहीं हैं।