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

systemd-coredump, systemd-coredump.socket, systemd-coredump@.service - ابزار و سرویس دریافت و ذخیره‌سازی هسته‌گرفت‌ها (core dumps)

/usr/lib/systemd/systemd-coredump

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

systemd-coredump@.service

systemd-coredump.socket

سرویس systemd-coredump@.service یک سرویس سیستمی برای پردازش هسته‌گرفت‌ها (core dumps) است. این سرویس خلاصه‌ای از رویداد را در systemd-journald.service(8) ثبت می‌کند، از جمله اطلاعات مربوط به شناسه فرایند، مالک، سیگنالی که فرایند را متوقف کرده است و در صورت امکان ردگیری پشته (stack trace). همچنین ممکن است هسته‌گرفت را برای پردازش‌های بعدی ذخیره کند. بخش «اطلاعات درباره فرایند کرش‌کرده» در زیر را ببینید.

رفتار یک برنامه خاص هنگام دریافت سیگنال توسط چند عامل کنترل می‌شود که به تفصیل در core(5) شرح داده شده‌اند. به‌ویژه، هسته‌گرفت تنها زمانی پردازش خواهد شد که محدودیت‌های منابع فرایند مربوطه (RLIMIT_CORE) کافی باشد.

هسته‌گرفت‌ها را می‌توان در ژورنال نوشت یا به‌صورت یک فایل ذخیره کرد. در هر دو حالت، می‌توان آن‌ها را برای پردازش بیشتر بازیابی کرد، برای مثال در gdb(1). به coredumpctl(1)، به‌ویژه دستورات فرعی list و debug مراجعه کنید.

به‌طور پیش‌فرض، systemd-coredump هسته‌گرفت را همراه با ردگیری پشته (در صورت امکان) در ژورنال ثبت می‌کند و خود هسته‌گرفت (تصویری از محتویات حافظه فرایند) را در یک فایل خارجی در /var/lib/systemd/coredump/ ذخیره می‌نماید. این هسته‌گرفت‌ها به‌طور پیش‌فرض پس از چند روز حذف می‌شوند؛ برای جزئیات به /usr/lib/tmpfiles.d/systemd.conf مراجعه کنید. توجه داشته باشید که حذف فایل‌های هسته از فایل‌سیستم و پاکسازی ورودی‌های ژورنال مستقل از یکدیگر هستند، و ممکن است فایل هسته بدون ورودی ژورنال وجود داشته باشد و ورودی‌های ژورنال ممکن است به فایل‌های هسته‌ای که از آن زمان حذف شده‌اند اشاره کنند. برخی از فراداده‌ها در قالب ویژگی‌های گسترش‌یافته (extended attributes) به فایل‌های هسته ضمیمه می‌شوند، بنابراین فایل‌های هسته حتی بدون وجود فراداده کامل در ورودی ژورنال نیز برای برخی اهداف مفید هستند.

برای جزئیات بیشتر به systemd Coredump Handling[1] مراجعه کنید.

برنامه اجرایی systemd-coredump کار اصلی را انجام می‌دهد. این برنامه دو بار فراخوانی می‌شود: یک بار توسط هسته به عنوان گرداننده (handler)، و بار دوم در systemd-coredump@.service تا داده‌ها را در ژورنال بنویسد و فایل هسته را پردازش و ذخیره کند.

هنگامی که هسته systemd-coredump را برای مدیریت یک هسته‌گرفت فراخوانی می‌کند، در حالت ممتازه (privileged) اجرا می‌شود و به سوکت ایجادشده توسط واحد systemd-coredump.socket متصل می‌گردد، که به نوبه خود یک نمونه غیرممتازه از systemd-coredump@.service را برای پردازش هسته‌گرفت ایجاد می‌کند. از این رو systemd-coredump.socket و systemd-coredump@.service واحدهای کمکی هستند که پردازش واقعی هسته‌گرفت‌ها را انجام می‌دهند و تحت مدیریت معمول سرویس‌ها قرار دارند.

همچنین امکان فراخوانی systemd-coredump با گزینه --backtrace وجود دارد. در این حالت، systemd-coredump انتظار یک ورودی ژورنال در Journal Export Format[2] روی ورودی استاندارد دارد. این ورودی باید حاوی یک فیلد MESSAGE= و هرگونه فیلد فراداده اضافی باشد که فراخواننده مناسب می‌داند. systemd-coredump فیلدهای فراداده اضافی را به همان روشی که برای هسته‌گرفت‌های دریافتی از هسته انجام می‌دهد ضمیمه خواهد کرد. در این حالت، هیچ هسته‌گرفتی در ژورنال ذخیره نمی‌شود.

سرویس systemd-coredump@.service به‌طور خودکار تلاش می‌کند تا هنگام کرش کردن یک فرایند، یک ردگیری پشته (stacktrace) را از آن استخراج کند. برای این ردگیری پشته، نمادها بر اساس اطلاعات اشکال‌زدایی (debug) تعبیه‌شده در تصویر ELF در حال کرش، یا اطلاعات اشکال‌زدایی معادل موجود به صورت جداگانه در سیستم‌عامل میزبان حل و فصل می‌شوند. برای فرایندهایی که درون کانتینرهای محلی یا سایر محیط‌های ایزوله (sandboxes) مبتنی بر فضای نام اتصال (mount namespace) کرش می‌کنند، این اطلاعات اشکال‌زدایی کمکی معمولاً روی میزبان در دسترس نیست (صرفاً به این دلیل که کانتینرها معمولاً نسخه‌های نرم‌افزاری متفاوتی نسبت به میزبان اجرا می‌کنند). 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 باید در پارامتر kernel.core_pattern در sysctl(8) پیکربندی شود. نحو این پارامتر در 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) (یا از هر فرایند دیگر، با استفاده از API مربوط به 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_CODE=2
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 ارائه‌شده توسط هسته تجزیه و تحلیل شده باشد (نیاز به هسته نسخه 6.16 دارد)، این فیلد وجود خواهد داشت و روی "1" تنظیم می‌شود. اگر این فیلد تنظیم نشده باشد، فرایند کرش‌کرده از طریق PID تحلیل شده است که مشخصاً در معرض شرایط رقابتی (race conditions) قرار دارد.

افزوده‌شده در نسخه 258.

COREDUMP_TIMESTAMP=

زمان کرش بر اساس گزارش هسته (به میکروثانیه از مبدأ زمان یا epoch).

افزوده‌شده در نسخه 248.

COREDUMP_RLIMIT=

محدودیت نرم منابع برای اندازه فایل هسته، نگاه کنید به getrlimit(2).

افزوده‌شده در نسخه 248.

COREDUMP_UNIT=, COREDUMP_SLICE=

نام‌های واحد سیستمی و برش (slice).

هنگامی که فرایند کرش‌کرده در کانتینر بوده است، این‌ها نام‌های واحد در خارج، در مدیر سیستم اصلی هستند.

افزوده‌شده در نسخه 248.

COREDUMP_CGROUP=

سی‌گروپ (cgroup) اصلی واحدِ فرایند کرش‌کرده.

هنگامی که فرایند کرش‌کرده در یک کانتینر بوده است، این مسیر کامل آن‌گونه که در خارج از کانتینر دیده می‌شود خواهد بود.

افزوده‌شده در نسخه 248.

COREDUMP_PROC_CGROUP=

اطلاعات گروه کنترلی (Control group) در قالبی که در /proc/self/cgroup استفاده می‌شود. در سیستم‌های دارای سلسله‌مراتب یکپارچه cgroup، این یک مسیر واحد با پیشوند "0::" است و در سیستم‌های قدیمی چندین مسیر با پیشوند شماره‌های کنترل‌کننده است.

هنگامی که فرایند کرش‌کرده در یک کانتینر بوده است، این مسیر کامل آن‌گونه که در خارج از کانتینر دیده می‌شود خواهد بود.

افزوده‌شده در نسخه 248.

COREDUMP_OWNER_UID=, COREDUMP_USER_UNIT=, COREDUMP_SESSION=

شناسه عددی UID کاربری که مالک نشست ورود یا واحد کاربری systemd فرایند کرش‌کرده است، واحد مدیر کاربر، و شناسه نشست. هر سه فیلد فقط برای فرایندهای کاربری وجود دارند.

هنگامی که فرایند کرش‌کرده در کانتینر بوده است، این‌ها مقادیر در خارج، در سیستم اصلی هستند.

افزوده‌شده در نسخه 248.

COREDUMP_SIGNAL_NAME=, COREDUMP_SIGNAL=

نام سیگنال پایان‌دهنده (با پیشوند "SIG" [4]) و مقدار عددی آن. (هر دو گنجانده شده‌اند زیرا شماره سیگنال‌ها بر اساس معماری متفاوت است.)

افزوده‌شده در نسخه 248.

COREDUMP_CODE=

دلیل ارسال سیگنال به عنوان یک مقدار عددی. این کد به عنوان فیلد si_code در ساختار siginfo_t تعریف شده و در sigaction(2) مستند شده است.

افزوده‌شده در نسخه 261.

COREDUMP_CWD=, COREDUMP_ROOT=

دایرکتوری کاری فعلی و دایرکتوری ریشه فرایند کرش‌کرده.

هنگامی که فرایند کرش‌کرده در یک کانتینر است، این مسیرها نسبت به ریشه فضای نام mount کانتینر هستند.

افزوده‌شده در نسخه 248.

COREDUMP_DUMPABLE=

فیلد PR_GET_DUMPABLE طبق گزارش هسته، نگاه کنید به prctl(2).

افزوده‌شده در نسخه 258.

COREDUMP_OPEN_FDS=

اطلاعات مربوط به توصیف‌کننده‌های باز فایل (file descriptors)، در قالب زیر: 
fd:/path/to/file
pos:     ...
flags:   ...
...
fd:/path/to/file
pos:     ...
flags:   ...
...

خط اول شامل شماره توصیف‌کننده فایل fd و مسیر است، در حالی که خطوط بعدی محتویات /proc/pid/fdinfo/fd را نشان می‌دهند.

افزوده‌شده در نسخه 248.

COREDUMP_EXE=

مقصد پیوند نمادین /proc/pid/exe.

هنگامی که فرایند کرش‌کرده در یک کانتینر است، آن مسیر نسبت به ریشه فضای نام mount کانتینر است.

افزوده‌شده در نسخه 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 (نقاط اتصال در فضای نام mount فرایند)، /proc/pid/status (متاداده‌های مختلف درباره فرایند).

برای اطلاعات بیشتر نگاه کنید به proc(5).

افزوده‌شده در نسخه 248.

COREDUMP_HOSTNAME=

نام میزبان (hostname) سیستم.

هنگامی که فرایند کرش‌کرده در کانتینر بوده است، این نام میزبان کانتینر است.

افزوده‌شده در نسخه 248.

COREDUMP_CONTAINER_CMDLINE=

برای فرایندهای در حال اجرا در یک کانتینر، خط فرمان فرایند ایجادکننده کانتینر (اولین فرایند والد با یک فضای نام mount متفاوت).

افزوده‌شده در نسخه 248.

COREDUMP=

هنگامی که هسته در ژورنال ذخیره می‌شود، خود تصویر هسته.

افزوده‌شده در نسخه 248.

COREDUMP_FILENAME=

هنگامی که هسته به صورت خارجی ذخیره می‌شود، مسیر فایل هسته.

افزوده‌شده در نسخه 248.

COREDUMP_TRUNCATED=

در صورتی که هسته‌گرفت ذخیره‌شده کوتاه (truncated) شده باشد، روی "1" تنظیم می‌شود. (تصویر جزئی هسته ممکن است هنوز توسط برخی ابزارها پردازش شود، اگرچه مشخصاً همه اطلاعات در دسترس نیست.)

افزوده‌شده در نسخه 248.

COREDUMP_PACKAGE_NAME=, COREDUMP_PACKAGE_VERSION=, COREDUMP_PACKAGE_JSON=

اگر فایل اجرایی حاوی یادداشت‌های متاداده ELF مربوط به package. باشد، تجزیه و ضمیمه خواهند شد. مقادیر package و version ماژول اصلی ELF (یعنی فایل اجرایی) به‌صورت جداگانه ضمیمه خواهند شد. محتوای قالب‌بندی‌شده با JSON تمام ماژول‌ها به‌صورت یک شیء JSON واحد ضمیمه می‌شود که هرکدام نام ماژول را به عنوان کلید دارند. برای اطلاعات بیشتر در مورد این قالب متاداده و محتوای آن، سند Package Metadata for Executable Files[5] را ببینید.

افزوده‌شده در نسخه 249.

MESSAGE=

پیام تولیدشده توسط systemd-coredump که در صورت تولید موفقیت‌آمیز، شامل ردگیری پشته است. هنگامی که systemd-coredump با --backtrace فراخوانی شود، این فیلد توسط فراخواننده ارائه می‌گردد.

افزوده‌شده در نسخه 248.

فیلدهای مختلف دیگری نیز در ورودی ژورنال وجود دارند، اما به فرایند ثبت رویداد، یعنی systemd-coredump مربوط می‌شوند و نه فرایند کرش‌کرده. نگاه کنید به systemd.journal-fields(7).

فیلدهای زیر (در صورت مشخص بودن) همراه با فایل خارجی فهرست‌شده در COREDUMP_FILENAME= به عنوان ویژگی‌های گسترش‌یافته (extended attributes) ذخیره می‌شوند:

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 Coredump Handling[1]

1.
systemd Coredump Handling
https://systemd.io/COREDUMP
2.
Journal Export Format
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.
Package Metadata for Executable Files
https://systemd.io/PACKAGE_METADATA_FOR_EXECUTABLE_FILES
systemd 261.2