Scroll to navigation

SYSTEMD-COREDUMP(8) systemd-coredump SYSTEMD-COREDUMP(8)

الاسم

systemd-coredump، systemd-coredump.socket، systemd-coredump@.service - الحصول على وحفظ ومعالجة تفريغات النواة

موجز

/usr/lib/systemd/systemd-coredump

/usr/lib/systemd/systemd-coredump --backtrace

systemd-coredump@.service

systemd-coredump.socket

الوصف

systemd-coredump@.service هي خدمة نظام لمعالجة تفريغات النواة. ستسجل ملخصًا للحدث في systemd-journald.service(8)، بما في ذلك معلومات عن معرف العملية، المالك، الإشارة التي قتلت العملية، وتتبع المكدس إن أمكن. قد تحفظ أيضًا تفريغ النواة للمعالجة لاحقًا. انظر قسم "معلومات عن العملية المنهارة" أدناه.

سلوك برنامج معين عند استقبال إشارة تحكمه عدة عوامل موصوفة بالتفصيل في core(5). على وجه الخصوص، لن تتم معالجة تفريغ النواة إلا عندما تكون حدود موارد العملية ذات الصلة (RLIMIT_CORE) كافية.

يمكن كتابة تفريغات النواة في السجل أو حفظها كملف. في كلتا الحالتين، يمكن استرجاعها لمزيد من المعالجة، على سبيل المثال في gdb(1). انظر coredumpctl(1)، ولا سيما الأفعال list و debug.

بشكل مبدئي، سيسجل systemd-coredump تفريغ النواة في السجل، بما في ذلك تتبع المكدس إن أمكن، ويخزن تفريغ النواة (صورة لمحتويات ذاكرة العملية) نفسه في ملف خارجي في /var/lib/systemd/coredump/. تُحذف تفريغات النواة هذه بعد بضعة أيام بشكل مبدئي؛ انظر /usr/lib/tmpfiles.d/systemd.conf للتفاصيل. لاحظ أن إزالة ملفات النواة من نظام الملفات وتطهير إدخالات السجل مستقلان، وقد يكون ملف النواة موجودًا بدون إدخال السجل، وقد تشير إدخالات السجل إلى ملفات نواة مُزالة منذ ذلك الحين. تُرفق بعض البيانات الوصفية بملفات النواة في شكل سمات موسعة، لذا تكون ملفات النواة مفيدة لبعض الأغراض حتى بدون البيانات الوصفية الكاملة المتاحة في إدخال السجل.

لمزيد من التفاصيل انظر معالجة تفريغ النواة في systemd[1].

استدعاء systemd-coredump

الملف القابل للتنفيذ systemd-coredump يقوم بالعمل الفعلي. يُستدعى مرتين: مرة كمعالج بواسطة النواة، والمرة الثانية في systemd-coredump@.service لكتابة البيانات فعليًا إلى السجل ومعالجة وحفظ ملف النواة.

عندما تستدعي النواة systemd-coredump لمعالجة تفريغ نواة، يعمل في وضع مميز، وسيتصل بالمقبس الذي أنشأته وحدة systemd-coredump.socket، والتي بدورها ستُولد مثيلًا غير مميز من systemd-coredump@.service لمعالجة تفريغ النواة. وبالتالي فإن systemd-coredump.socket و systemd-coredump@.service هما وحدتان مساعدتان تقومان بالمعالجة الفعلية لتفريغات النواة وتخضعان لإدارة الخدمة العادية.

من الممكن أيضًا استدعاء systemd-coredump مع الخيار --backtrace. في هذه الحالة، يتوقع systemd-coredump إدخال سجل في السجل تنسيق تصدير السجل[2] على الإدخال القياسي. يجب أن يحتوي الإدخال على حقل MESSAGE= وأي حقول بيانات وصفية إضافية يراها المتصل معقولة. سيُضيف systemd-coredump حقول بيانات وصفية إضافية بنفس الطريقة التي يفعلها لتفريغات النواة المستلمة من النواة. في هذا الوضع، لا يُخزن أي تفريغ نواة في السجل.

تفريغات النواة في الحاويات/مساحات الأسماء

ستحاول خدمة systemd-coredump@.service آليًا استخراج تتبع مكدس من عملية أثناء انهيارها. سيتم حل رموز تتبع المكدس هذه بناءً على معلومات التصحيح المضمنة في صورة ELF المنهارة، أو معلومات التصحيح المكافئة المتاحة بشكل منفصل على نظام التشغيل المضيف. بالنسبة للعمليات التي تنهار داخل حاويات محلية أو صناديق رمل أخرى قائمة على مساحة أسماء التحميل، فإن معلومات التصحيح المساعدة هذه غير متاحة عادةً على المضيف (ببساطة لأن الحاويات تشغل عادةً إصدارات برامج مختلفة عن المضيف). يوفر systemd-coredump آليتين لمعالجة هذا:

1.بالنسبة لحاويات نظام التشغيل الكاملة التي تشغل systemd داخلها، من الجيد تمكين CoredumpReceive= على الوحدة (انظر systemd.resource-control(5))، مما يضمن محاولة إعادة توجيه تفريغات النواة للحاوية إلى systemd-coredump@.service الذي يعمل داخل الحاوية، أي أن الحاوية تقوم بمعالجة وتخزين تفريغات النواة الخاصة بها. لاحظ أن systemd-nspawn(8) يضع هذا الوضع كمبدئي إذا تم استدعاؤه مع المفتاح --boot. يُوصى عمومًا بوضع التشغيل هذا لأسباب أمنية: تتم معالجة تفريغ النواة الحساسة أمنيًا داخل حدود الحاوية نفسها، بواسطة كود الحاوية الخاص، مدعومًا بتخزين الحاوية الخاص.

2.بدلاً من ذلك، بالنسبة للحاويات الأكثر تقييدًا (التي لا تشغل نظام init مناسبًا كـ PID 1)، من الممكن تمكين معالجة تفريغ النواة على المضيف، مع الوصول إلى بيانات معلومات التصحيح من الحاوية نفسها. يجب تمكين وضع التشغيل هذا عبر EnterNamespace= في coredump.conf(5)، ويكون مبدئيًا معطلاً، لأسباب أمنية.

إذا تم تمكين كل من CoredumpReceive= على وحدة الحاوية التي ينتمي إليها تفريغ النواة، و EnterNamespace= في ملف التكوين coredump.conf، فإن الأول له الأسبقية.

الضبط

بالنسبة للبرامج التي بدأها systemd، يمكن تعيين حدود موارد العملية بواسطة التوجيه LimitCORE=، انظر systemd.exec(5).

لكي تستخدمه النواة لمعالجة تفريغات النواة، يجب تكوين systemd-coredump في معامل sysctl(8) kernel.core_pattern. يتم شرح بناء جملة هذا المعامل في core(5). يقوم systemd بتثبيت الملف /usr/lib/sysctl.d/50-coredump.conf الذي يهيئ kernel.core_pattern وفقًا لذلك. يمكن إخفاء هذا الملف أو تجاوزه لاستخدام إعداد مختلف باتباع قواعد sysctl.d(5) العادية. إذا تم تعديل تكوين sysctl، فيجب تحديثه في النواة قبل أن يصبح ساري المفعول، انظر sysctl(8) و systemd-sysctl(8).

لاستخدامه في وضع --backtrace، يجب تثبيت معالج تتبع خلفي مناسب على جانب المرسل. على سبيل المثال، في حالة python(1)، يعني هذا وجوب تثبيت sys.excepthook، انظر systemd-coredump-python[3].

يُهيأ سلوك systemd-coredump نفسه عبر ملف التهيئة /etc/systemd/coredump.conf والمقتطفات المقابلة /etc/systemd/coredump.conf.d/*.conf، انظر coredump.conf(5). يُستدعى مثيل جديد من systemd-coredump عند استلام كل تفريغ أساسي. لذلك، ستصبح التغييرات في هذه الملفات سارية المفعول في المرة التالية التي يُستلم فيها تفريغ أساسي.

تُقيد الموارد المستخدمة بواسطة ملفات التفريغ الأساسي بطريقتين. يمكن ضبط معاملات مثل الحجم الأقصى للتفريغات الأساسية والملفات الملتقطة في ملفات /etc/systemd/coredump.conf والمقتطفات المذكورة أعلاه. بالإضافة إلى ذلك، يُقيد وقت تخزين ملفات التفريغ الأساسي بواسطة systemd-tmpfiles، والإعدادات المقابلة موجودة مبدئيًا في /usr/lib/tmpfiles.d/systemd.conf. المبدئي هو حذف التفريغات الأساسية بعد بضعة أيام؛ انظر الملف أعلاه للتفاصيل.

تعطيل معالجة التفريغ الأساسي

لتعطيل المعالجة التي قد تكون كثيفة الموارد بواسطة systemd-coredump، اضبط

Storage=none
ProcessSizeMax=0

في coredump.conf(5).

معلومات حول العملية المتعطلة

يمكن استخدام coredumpctl(1) لاسترداد التفريغات الأساسية المحفوظة بغض النظر عن موقعها، وعرض المعلومات، ومعالجتها، على سبيل المثال، بتمريرها إلى مصحح أخطاء غنو (gdb).

يمكن أيضًا عرض البيانات المخزنة في السجل باستخدام journalctl(1) كالمعتاد (أو من أي عملية أخرى، باستخدام واجهة برمجة تطبيقات sd-journal(3)). تحتوي الرسائل ذات الصلة على MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1:

$ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose
...
MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
COREDUMP_PID=552351
COREDUMP_UID=1000
COREDUMP_GID=1000
COREDUMP_SIGNAL_NAME=SIGSEGV
COREDUMP_SIGNAL=11
COREDUMP_TIMESTAMP=1614342930000000
COREDUMP_COMM=Web Content
COREDUMP_EXE=/usr/lib64/firefox/firefox
COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope
COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser ...
COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-....scope
COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web....552351.....zst
...

تُحفظ الحقول التالية (إذا كانت معروفة) مع إدخال السجل

COREDUMP_UID=, COREDUMP_PID=, COREDUMP_GID=

رقم العملية (PID)، ورقم المستخدم المالك (UID)، ورقم المجموعة (GID) للعملية المتعطلة.

عندما كانت العملية المتعطلة جزءًا من حاوية (أو في مساحة اسم عملية أو مستخدم بشكل عام)، فهذه هي القيم كما تُرى خارجيًا، في مساحة الاسم حيث يعمل systemd-coredump.

أُضيف في الإصدار 248.

COREDUMP_BY_PIDFD=

إذا حُللت العملية المتعطلة باستخدام PIDFD مقدم من النواة (يتطلب نواة v6.16)، فسيكون هذا الحقل موجودًا ومضبوطًا على "1". إذا لم يُضبط هذا الحقل، فقد حُللت العملية المتعطلة عبر PID، والذي يُعرف بأنه عرضة لحالات السباق.

أُضيف في الإصدار 258.

COREDUMP_TIMESTAMP=

وقت التعطل كما أبلغت عنه النواة (بالميكروثانية منذ الحقبة).

أُضيف في الإصدار 248.

COREDUMP_RLIMIT=

حد المورد الناعم لحجم ملف التفريغ الأساسي، انظر getrlimit(2).

أُضيف في الإصدار 248.

COREDUMP_UNIT=, COREDUMP_SLICE=

أسماء الوحدة والشريحة النظامية.

عندما كانت العملية المتعطلة داخل حاوية، فهذه هي أسماء الوحدات خارج الحاوية، في مدير النظام الرئيسي.

أُضيف في الإصدار 248.

COREDUMP_CGROUP=

مجموعة التحكم الأساسية لوحدة العملية المتعطلة.

عندما كانت العملية المتعطلة داخل حاوية، هذا هو المسار الكامل كما يُرى من خارج الحاوية.

أُضيف في الإصدار 248.

COREDUMP_PROC_CGROUP=

معلومات مجموعة التحكم بالتنسيق المستخدم في /proc/self/cgroup. على الأنظمة ذات التسلسل الهرمي الموحد لمجموعات التحكم، هذا مسار واحد مسبوق بـ "0::"، ومسارات متعددة مسبوقة بأرقام وحدات التحكم على الأنظمة القديمة.

عندما كانت العملية المتعطلة داخل حاوية، هذا هو المسار الكامل كما يُرى من خارج الحاوية.

أُضيف في الإصدار 248.

COREDUMP_OWNER_UID=، COREDUMP_USER_UNIT=، COREDUMP_SESSION=

المُعرّف الرقمي UID للمستخدم المالك لجلسة الدخول أو وحدة مستخدم systemd للعملية المتعطلة، ووحدة مدير المستخدم، ومعرّف الجلسة. الحقول الثلاثة موجودة فقط لعمليات المستخدم.

عندما كانت العملية المتعطلة داخل حاوية، فهذه هي القيم خارج الحاوية، في النظام الرئيسي.

أُضيف في الإصدار 248.

COREDUMP_SIGNAL_NAME=، COREDUMP_SIGNAL=

اسم الإشارة المُنهية (مع البادئة "SIG" [4]) والقيمة الرقمية. (كلا القيمتين مُدرجتان لأن أرقام الإشارات تختلف حسب البنية.)

أُضيف في الإصدار 248.

COREDUMP_CWD=، COREDUMP_ROOT=

دليل العمل الحالي والدليل الجذر للعملية المتعطلة.

عندما تكون العملية المتعطلة داخل حاوية، هذه المسارات نسبية لجذر مساحة أسماء التثبيت للحاوية.

أُضيف في الإصدار 248.

COREDUMP_DUMPABLE=

حقل PR_GET_DUMPABLE كما يُبلغ عنه النواة، انظر prctl(2).

أُضيف في الإصدار 258.

COREDUMP_OPEN_FDS=

معلومات عن واصفات الملفات المفتوحة، بالتنسيق التالي: 

fd:/path/to/file
pos:     ...
flags:   ...
...
fd:/path/to/file
pos:     ...
flags:   ...
...

السطر الأول يحتوي على رقم واصف الملف fd والمسار، بينما تُظهر الأسطر التالية محتويات /proc/pid/fdinfo/fd.

أُضيف في الإصدار 248.

COREDUMP_EXE=

وجهة الرابط الرمزي /proc/pid/exe.

عندما تكون العملية المتعطلة داخل حاوية، هذا المسار نسبي لجذر مساحة أسماء التثبيت للحاوية.

أُضيف في الإصدار 248.

COREDUMP_CMDLINE=، COREDUMP_COMM=، COREDUMP_ENVIRON=، COREDUMP_PROC_AUXV=، COREDUMP_PROC_LIMITS=، COREDUMP_PROC_MAPS=، COREDUMP_PROC_MOUNTINFO=، COREDUMP_PROC_STATUS=

حقول تُعيّن الإدخالات الخاصة بكل عملية في نظام الملفات /proc/: /proc/pid/cmdline (سطر الأوامر للعملية المتعطلة)، /proc/pid/comm (اسم الأمر المرتبط بالعملية)، /proc/pid/environ (كتلة البيئة للعملية المتعطلة)، /proc/pid/auxv (المتجه المساعد للعملية المتعطلة، انظر getauxval(3))، /proc/pid/limits (حدود الموارد اللينة والصلبة)، /proc/pid/maps (مناطق الذاكرة المرئية للعملية وأذونات الوصول إليها)، /proc/pid/mountinfo (نقاط التثبيت في مساحة أسماء التثبيت للعملية)، /proc/pid/status (بيانات وصفية متنوعة عن العملية).

انظر proc(5) لمزيد من المعلومات.

أُضيف في الإصدار 248.

COREDUMP_HOSTNAME=

اسم المضيف للنظام.

عندما كانت العملية المنهارة في حاوية، هذا هو اسم مضيف الحاوية.

أُضيف في الإصدار 248.

COREDUMP_CONTAINER_CMDLINE=

للعمليات الجارية في حاوية، سطر أوامر العملية التي أنشأت الحاوية (أول عملية أب ذات مساحة تثبيت مختلفة).

أُضيف في الإصدار 248.

COREDUMP=

عند تخزين النواة في السجل، صورة النواة نفسها.

أُضيف في الإصدار 248.

COREDUMP_FILENAME=

عند تخزين النواة خارجيًا، المسار إلى ملف النواة.

أُضيف في الإصدار 248.

COREDUMP_TRUNCATED=

يُضبط على "1" عندما تم اقتطاع تفريغ النواة المحفوظ. (قد تظل صورة نواة جزئية قابلة للمعالجة بواسطة بعض الأدوات، رغم أن المعلومات غير متوفرة بالكامل بوضوح.)

أُضيف في الإصدار 248.

COREDUMP_PACKAGE_NAME=, COREDUMP_PACKAGE_VERSION=, COREDUMP_PACKAGE_JSON=

إذا احتوى الملف التنفيذي على ملاحظات ELF لبيانات تعريف .package، فسيتم تحليلها وإرفاقها. سيتم إلحاق package و version لوحدة ELF 'الرئيسية' (أي الملف التنفيذي) بشكل فردي. سيتم إلحاق محتوى جميع الوحدات بتنسيق JSON ككائن JSON واحد، مع اسم الوحدة كمفتاح لكل منها. لمزيد من المعلومات حول تنسيق ومحتوى هذه البيانات التعريفية، انظر وثيقة بيانات تعريف الحزمة للملفات التنفيذية[5].

أُضيف في الإصدار 249.

MESSAGE=

الرسالة المولدة بواسطة systemd-coredump والتي تتضمن التتبع العكسي إذا تم توليده بنجاح. عند استدعاء systemd-coredump مع --backtrace، يتم توفير هذا الحقل بواسطة المستدعي.

أُضيف في الإصدار 248.

توجد حقول أخرى متنوعة في إدخال السجل، لكنها تتعلق بعملية التسجيل، أي systemd-coredump، وليس العملية المنهارة. انظر systemd.journal-fields(7).

يتم حفظ الحقول التالية (إذا كانت معروفة) مع الملف الخارجي المدرج في COREDUMP_FILENAME= كسمات ممتدة:

user.coredump.pid, user.coredump.uid, user.coredump.gid, user.coredump.signal, user.coredump.timestamp, user.coredump.rlimit, user.coredump.hostname, user.coredump.comm, user.coredump.exe

هذه هي نفس COREDUMP_PID=, COREDUMP_UID=, COREDUMP_GID=, COREDUMP_SIGNAL=, COREDUMP_TIMESTAMP=, COREDUMP_RLIMIT=, COREDUMP_HOSTNAME=, COREDUMP_COMM=, و COREDUMP_EXE=، الموضحة أعلاه.

أُضيف في الإصدار 248.

يمكن عرضها باستخدام getfattr(1). لملف النواة الموصوف في إدخال السجل الموضح أعلاه:

$ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web....552351.....zst
# file: /var/lib/systemd/coredump/core.Web....552351.....zst
user.coredump.pid="552351"
user.coredump.uid="1000"
user.coredump.gid="1000"
user.coredump.signal="11"
user.coredump.timestamp="1614342930000000"
user.coredump.comm="Web Content"
user.coredump.exe="/usr/lib64/firefox/firefox"
...

انظر أيضًا

coredump.conf(5), coredumpctl(1), systemd-journald.service(8), systemd-tmpfiles(8), core(5), sysctl.d(5), systemd-sysctl.service(8), معالجة تفريغ النواة في systemd[1]

ملاحظات

1.
معالجة تفريغ النواة في systemd
https://systemd.io/COREDUMP
2.
تنسيق تصدير اليوميات
https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format
3.
systemd-coredump-python
https://github.com/systemd/systemd-coredump-python
4.
تتوقع kill(1) أسماء الإشارات بدون البادئة؛ تستخدم kill(2) البادئة؛ جميع أدوات systemd تقبل أسماء الإشارات مع البادئة وبدونها.
5.
بيانات الحزمة الوصفية للملفات القابلة للتنفيذ
https://systemd.io/PACKAGE_METADATA_FOR_EXECUTABLE_FILES/

ترجمة

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.

systemd 260.1