تصور کنید که با خوشحالی روی سیستم لینوکس خود کار می‌کنید، شاید در حال کامپایل یک بسته، اجرای به‌روزرسانی‌ها یا مرور وب هستید و ناگهان، صفحه نمایش شما هنگ کرده و دیواری از متن مرموز ظاهر می‌شود: Kernel panic – not syncing: Attempted to kill init! و کرنل پنیک رخ می‌دهد.
پیش از آنکه دچار نگرانی شوید، اجازه دهید با آرامش به موضوع بپردازیم و بیاموزیم چگونه می‌توان یک خطای کرنل (Kernel Panic) را درک، شبیه‌سازی و برطرف کرد.
کرنل پنیک (Kernel Panic) چیست؟
کرنل پنیک (Kernel Panic) یک سازوکار ایمنی در هسته‌ی لینوکس است که در مواجهه با خطاهای بحرانی غیرقابل بازیابی، فعال می‌شود. این اقدام با هدف جلوگیری از آسیب بیشتر به سیستم انجام می‌گیرد.
هسته‌ی لینوکس به‌عنوان قلب سیستم‌عامل، وظایفی حیاتی همچون مدیریت حافظه، ارتباط با سخت‌افزار و اجرای فرآیندها را بر عهده دارد. در صورتی که اختلالی جدی در سطوح پایین هسته رخ دهد مانند دسترسی یک درایور معیوب به ناحیه‌ای نامعتبر از حافظه یا از کار افتادن یکی از مولفه‌های کلیدی، هسته برای جلوگیری از بروز اختلالات بیشتر، بلافاصله سیستم را متوقف می‌کند.
می‌توان این وضعیت را به فعال شدن ترمز اضطراری در یک خودرو تشبیه کرد؛ هنگامی که شرایط بحرانی می‌شود، سیستم برای حفظ ایمنی، به‌طور کامل متوقف می‌شود. قبلا مطلبی با عنوان kernel panic چیست؟ را منتظر کرده‌ایم که توضیحات بیشتری در این باره می‌دهد.
دلایل رایج کرنل پنیک
در این بخش، به برخی از رایج‌ترین عوامل بروز کرنل پنیک در سیستم‌عامل لینوکس می‌پردازیم؛ عواملی که به‌عنوان مظنونین همیشگی شناخته می‌شوند و اغلب موجب از کار افتادن سیستم می‌گردند:
- مشکلات سخت‌افزاری:
حافظه‌ی RAM معیوب، افزایش بیش از حد دمای پردازنده، یا خرابی دیسک‌های ذخیره‌سازی از جمله عوامل سخت‌افزاری هستند که می‌توانند با ایجاد ناپایداری در حافظه، خطاهای بحرانی در فایل سیستم و اختلال در فرآیند بوت، منجر به بروز کرنل پنیک شوند. - درایورهای ناسازگار یا نصب‌شده به‌صورت دستی:
استفاده از درایورهای شخص ثالث یا آن‌هایی که با نسخه‌ی فعلی کرنل مطابقت ندارند، به‌ویژه هنگام بارگذاری از طریق ابزارهایی نظیر modprobe، ممکن است بلافاصله موجب پنیک شوند. - خرابی فایل‌های سیستمی حیاتی:
آسیب‌دیدگی یا حذف فایل‌های کلیدی نظیر /etc/fstab، /sbin/init یا ایمیج initramfs می‌تواند فرآیند بوت را مختل کرده و در نتیجه، سیستم را وارد وضعیت کرنل پنیک نماید. - پیکربندی نادرست GRUB یا اطلاعات ناهماهنگ دیسک:
استفاده از UUID نادرست، برچسب‌های اشتباه پارتیشن، یا پیکربندی ناقص مربوط به کرنل یا initramfs در فایل‌های GRUB، ممکن است فرآیند بوت را مختل کرده و حتی پیش از بارگیری سیستم‌عامل، موجب بروز پنیک شود. - حذف یا آسیب به فرآیندهای حیاتی سیستم:
حذف تصادفی فایل‌هایی مانند /sbin/init یا پایان دادن اجباری به فرآیند PID 1، منجر به از دست رفتن فرآیند اصلی سیستم شده و در نهایت، یک کرنل پنیک غیرقابل بازیابی را در پی خواهد داشت.
نحوه شبیه‌سازی Kernel Panic (به طور ایمن!)
هشدار: این کار را روی یک سیستم عملیاتی امتحان نکنید. همیشه در یک ماشین مجازی (VirtualBox، KVM یا QEMU) یا کانتینر آزمایش کنید.
گزینه ۱: راه‌اندازی Kernel Panic با استفاده از /proc/sysrq-trigger
یکی از امن‌ترین و کنترل‌شده‌ترین راه‌ها برای شبیه‌سازی kernel panic، استفاده از رابط SysRq (System Request) ارائه شده توسط هسته لینوکس است که اغلب توسط توسعه‌دهندگان و مدیران سیستم برای اشکال‌زدایی سناریوهای خرابی یا آزمایش سیاست‌های بازیابی سیستم مانند ریبوت خودکار استفاده می‌شود.
رابط SysRq از طریق /proc/sys/kernel/sysrq کنترل می‌شود و برای فعال کردن آن، دستور زیر را اجرا کنید:
echo 1 | sudo tee /proc/sys/kernel/sysrq
حالا، برای شبیه‌سازی کرنل پنیک، دستور زیر را اجرا کنید:
echo c | sudo tee /proc/sysrq-trigger
به محض اجرای این دستور، کرنل متوقف می‌شود، یک پیام خطا نمایش می‌دهد و سیستم را فریز می‌کند.
فعال کردن خطای هسته با استفاده از رابط اشکال‌زدایی
یکی دیگر از راه‌های ایمن برای شبیه‌سازی کرنل پنیک، استفاده از رابط SysRq داخلی لینوکس یا فعال کردن دستی آن با استفاده از ماژول kernel panic، در صورت وجود، است.
استفاده از SysRq برای فعال کردن کرنل پنیک
ابتدا، مطمئن شوید که ویژگی SysRq فعال است:
echo 1 > /proc/sys/kernel/sysrq
سپس کرنل پنیک را فعال کنید، که بلافاصله با مجبور کردن سیستم به کرش کردن، باعث kernel panic می‌شود – برای آزمایش رفتار کرنل پنیک یا پیکربندی راه‌اندازی مجدد خودکار عالی است.
echo c > /proc/sysrq-trigger
روش ۲: بارگذاری ماژول کرش کرنل (در صورت وجود)
بعضی از کرنل‌ها شامل ماژولی مخصوص برای ایجاد کرش هستند. می‌توانید آن را با موارد زیر بارگذاری کنید:
sudo modprobe crash
پس از بارگذاری، بسته به پیکربندی کرنل شما، ممکن است قابلیت اشکال‌زدایی اضافی ارائه دهد. با این حال، همه توزیع‌ها این ماژول را ارائه نمی‌دهند و ممکن است برای ایمنی در کرنلهای پروداکشن، غیرفعال باشد.
اگر modprobe crash خطایی را برمی‌گرداند، ممکن است ماژول در دسترس نباشد یا در کرنل شما تعبیه نشده باشد. می‌توانید با موارد زیر بررسی کنید:
modinfo crash
نحوه رفع کرش کرنل در لینوکس
بیایید فرآیند گام به گام تشخیص و رفع کرش کرنل را بررسی کنیم.
۱. ریبوت و بررسی گزارش‌های سیستم
پس از کرش کرنل، سیستم شما احتمالا به طور کامل هنگ می‌کند. باید دستگاه را به صورت دستی یا با فشار دادن دکمه پاور یا با استفاده از کلید reset، ریبوت کنید.
پس از راه‌اندازی مجدد سیستم (یا بوت شدن لایو)، اولین چیزی که باید بررسی شود، لاگ‌های سیستم است تا با استفاده از دستور journalctl زیر، علت خرابی را شناسایی کنید. این دستور لاگ‌های دقیقی از بوت قبلی، از جمله خطاهای هسته و سرویس‌هایی که از کار افتاده‌اند، را نشان می‌دهد.
journalctl -xb
همچنین، می‌توانید kernel message buffer و فایل‌های لاگ را بررسی کنید:
dmesg | less OR cat /var/log/kern.log | less
به دنبال خطوطی باشید که به panic، segfault یا kernel bug اشاره می‌کنند. به نام ماژول‌ها، خطاهای سخت‌افزاری یا مسیرهای فایل توجه کنید.
۲. بوت شدن به یک کرنل قدیمی‌تر
پس از به‌روزرسانی کرنل، بروز مشکل در سیستم به دلیل ناسازگاری درایور یا ساخت ناقص کرنل، غیرمعمول نیست. خوشبختانه، GRUB معمولا چندین نسخه کرنل را نصب نگه می‌دارد و به شما امکان می‌دهد به راحتی به نسخه قبلی برگردید.
برای بوت شدن به یک کرنل قدیمی‌تر، کافیست سیستم خود را ریبوت کنید، در منوی GRUB دکمه Esc را فشار دهید (اگر به طور خودکار ظاهر نشد) و یک نسخه کرنل قبلی را از لیست انتخاب کنید،
به عنوان مثال، اگر یک کرنل ۶.x جدیدتر باعث ایجاد مشکل می‌شود، ۵.۱۵.۰-۹۲-generic.
پس از شناسایی یک نسخه کرنل پایدار، می‌توانید آن را به عنوان پیش‌فرض تنظیم کنید تا GRUB همیشه به طور خودکار به آن بوت شود.
sudo apt install linux-image-<old-version> sudo grub-set-default 1 # set the older kernel as default
از grep menuentry /boot/grub/grub.cfg برای یافتن نام دقیق ورودی کرنل مورد نظر خود استفاده کنید.
۳. بازسازی Initramfs (سیستم فایل اولیه RAM)
initramfs (یا initrd) یک فایل سیستم روت کوچک و موقت است که در طول فرآیند بوت، قبل از نصب فایل سیستم روت واقعی شما، در حافظه بارگذاری می‌شود و شامل درایورها و ابزارهای ضروری مورد نیاز برای بوت شدن سیستم است.
اگر این ایمیج خراب شود، با کرنل ناسازگار شود یا به طور کامل از بین برود، سیستم شما ممکن است درست پس از اینکه GRUB کنترل را به کرنل واگذار می‌کند، دچار مشکل شود.
برای بازسازی initramfs، اگر سیستم شما شروع به کار نمی‌کند، از طریق یک CD/USB زنده بوت نموده و پارتیشن root خود را نصب کنید.
sudo update-initramfs -u -k all
اگر می‌خواهید فقط برای کرنل فعلی بازسازی کنید:
sudo update-initramfs -c -k $(uname -r)
پس از بازسازی، سیستم خود را ریبوت کنید.
sudo reboot
۴. تعمیر فایل سیستم
اگر کرنل پنیک شامل پیام‌هایی مانند unable to mount root fs یا VFS: unable to mount root باشد، احتمال زیادی وجود دارد که فایل سیستم روت یا بوت شما خراب شده باشد، که می‌تواند به دلیل خاموش شدن نامناسب، قطعی برق یا خطاهای دیسک رخ دهد.
برای تعمیر فایل سیستم ، از lsblk یا fdisk برای یافتن پارتیشن روت یا بوت لینوکس خود استفاده کنید.
lsblk
سپس، fsck را برای تعمیر سیستم فایل اجرا کنید.
sudo fsck /dev/sda1
/dev/sda1 را با پارتیشن روت یا بوت واقعی خود جایگزین کنید.
۵. تشخیص مشکلات سخت‌افزاری
گاهی اوقات، خطای کرنل پنیک به هیچ وجه تقصیر نرم‌افزار شما نیست و این سخت‌افزار است که بی‌سروصدا در زیر آن دچار مشکل می‌شود. تشخیص خطاهای حافظه و دیسک تا زمانی که آسیب واقعی ایجاد نکنند، بسیار دشوار است.
از smartctl از پکیج smartmontools برای بررسی سلامت درایو و آمار خطا استفاده کنید:
sudo smartctl -a /dev/sda
به دنبال علائم هشدار دهنده‌ای مانند Reallocated_Sector_Ct (بخش‌های بد قبلا منتقل شده‌اند)، Pending_Sector_Ct (بخش‌هایی که منتظر تخصیص مجدد هستند) یا Current_Pending_Sector (یک پرچم قرمز بزرگ برای بی‌ثباتی) باشید.
اگر هر یک از این مقادیر در حال افزایش است، نشانگر قوی از خرابی درایو شماست و باید هر چه سریع‌تراز داده‌های خود نسخه بکاپ تهیه و دیسک را جایگزین کنید.
۶. رفع مشکل بوت لودر GRUB
بوت لودر GRUB با پیکربندی نادرست یا خراب، یکی از دلایل رایج کرنل پنیک است، به خصوص پس از ارتقای کرنل، تنظیمات بوت دوگانه یا تغییرات دیسک. اگر GRUB نتواند پارتیشن روت یا ایمیج اولیه شما را به درستی پیدا کند، ممکن است سیستم بوت نشود و خطای پنیک نمایش دهد.
رفع مشکل GRUB با استفاده از یک CD زنده یا USB قابل بوت.
sudo mount /dev/sda1 /mnt sudo grub-install --root-directory=/mnt /dev/sda sudo update-grub
مطمئن شوید که etc/fstab/ دارای UUID های صحیح است و می‌توانید آنها را با استفاده از موارد زیر بررسی کنید:
blkid
خرید VPS لینوکس با دسترسی کامل SSH و منابع اختصاصی، مناسب برای برنامه‌نویسان، توسعه‌دهندگان و مدیران سایت در پارسدو فراهم است.
چگونه از کرنل پنیک جلوگیری کنیم (مانند یک حرفه‌ای)
همیشه نمی‌توان از kernel panic اجتناب کرد، به خصوص با سخت‌افزار خراب، پیروی از چند روش هوشمندانه می‌تواند احتمال مواجهه با آنها را به میزان قابل توجهی کاهش دهد.
در ادامه نحوه محافظت پیشگیرانه از سیستم لینوکس خود در برابر کرنل پنیک آورده شده است:
- از حذف یا تغییر دستی فایل‌های حیاتی سیستم خودداری کنید.
- هرگز کرنل را بدون آزمایش اولیه روی یک سرور پروداکشن زنده به‌روزرسانی نکنید.
- برای پایداری از کرنلهای LTS (پشتیبانی طولانی مدت) استفاده کنید.
- همیشه حداقل دو نسخه از کرنل را نصب کنید.
- از بکاپ‌ها (به‌خصوص از boot، /etc/ و پیکربندی‌های مهم) استفاده کنید.
- با استفاده از kdump، داده‌های خرابی خودکار را برای ثبت panic logs فعال کنید.
ریبوت خودکار پس از panic
برای جلوگیری از هنگ کردن دستگاه، می‌توانید کرنل را طوری پیکربندی کنید که پس از Panic به‌طور خودکار ریبوت شود.
این را به فایل etc/sysctl.conf/ اضافه کنید، که به سیستم می‌گوید ۱۰ ثانیه پس از پنیک، ریبوت شود.
kernel.panic = 10
آن را اعمال کنید.
sudo sysctl -p
جمع‌بندی
کرنل پنیک می‌تواند به‌خصوص برای مبتدیان وحشتناک به نظر برسد، اما وقتی معنی و نحوه برخورد با آن را بفهمید، فقط به یک معمای لینوکس برای حل تبدیل می‌شود.
نکته کلیدی این است که آرام باشید، وارد یک سیستم بازیابی یا زنده شوید، لاگ‌ها را جمع‌آوری کنید، مشخص کنید چه چیزی تغییر کرده است (به‌روزرسانی کرنل، خرابی سخت‌افزار، اشتباه پیکربندی) و به‌طور روشمند آسیب را برطرف کنید و اگر واقعا می‌خواهید یک نینجای لینوکس شوید، شبیه‌سازی کرنل پنیک را در یک آزمایشگاه مجازی امتحان کرده و مهارت‌های بازیابی خود را تمرین نمائید.
