TGViewer
کدهالیک | codehalic کدهالیک | codehalic @codehalics · 4.15K subscribers
Post #762 721
کدهالیک | codehalic سناریویی که اتفاق افتاد این بود داستان از این قرار بود که سرور لینوکس شما که میزبان سرویس‌های حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی)…
۱. بررسی تاریخچه لاگین‌ها و خاموشی‌ها (last -x)
اولین قدم این بود که ببینیم آیا کسی دکمه خاموشی رو زده؟
خروجی دستور last نشون داد که آخرین باری که سرور به صورت نرمال shutdown شده، مربوط به ماه‌ها پیش بوده.

۲. مدرک سخت‌افزاری: وحشتِ سیستم‌فایل (recovering journal)
وقتی لینوکس نرمال خاموش میشه، درایوها رو با احترام می‌بنده (Unmount). ما رفتیم سراغ لاگ‌های لحظه روشن شدن سرور با دستور:
journalctl -b | grep -i "recovering journal"
چی پیدا کردیم؟ دیدیم سرویس systemd-fsck به شدت درگیر ریکاوری کردن پارتیشن‌های sda2، lv_var و lv_home شده! این یعنی درایوها در حالت کثیف (Dirty) رها شده بودن و برقشون یهو قطع شده بوده. این اولین "تیر خلاص" به ادعای پشتیبانی بود.

۳. مدرک اپلیکیشنی: اعترافِ پستگرس (PostgreSQL)
دیتابیس‌ها به شدت روی داده‌ها حساسن. ما رفتیم سراغ لاگ کانتینر دیتابیس:
docker logs <container_id>
چی پیدا کردیم؟ این شاه‌بیتِ ماجرا بود! پستگرس لاگ انداخته بود که:
database system was not properly shut down; automatic recovery in progress
یعنی دیتابیس وسط کار خفه شده بود! تازه پستگرس زمان دقیق قطعی رو هم لو داد: ۱۴ ژوئن ساعت ۲۱:۳۱. اینجا دیگه ۱۰۰٪ مطمئن شدیم که سرور به صورت Hard Power Cut خاموش شده.

۴. مدرک پلتفرمی: تقلای انجین داکر (Docker Daemon)
برای اینکه نشون بدیم حتی داکر هم غافلگیر شده، لاگ‌های سرویس داکر رو چک کردیم:
journalctl -u docker.service -b
چی پیدا کردیم؟ ده‌ها خط ارور با عنوان Removing stale sandbox. این نشون داد که داکر نتونسته در زمان قطعی، سیگنال SIGTERM رو به کانتینرها بفرسته و محیط‌های شبکه‌ای (Sandboxes) رو به درستی پاک کنه. در نتیجه موقع روشن شدن، مجبور شده زباله‌های به‌جا مونده از دفعه قبل رو دستی پاک کنه.

۵. اثبات بی‌گناهی لینوکس (رد کردن ادعای کِرَش)
برای اینکه پشتیبانی نتونه بگه "لینوکس خودتون باگ خورده و هنگ کرده":

پوشه کرش‌های هسته لینوکس (/var/crash/) رو چک کردیم و دیدیم total 0 (کاملاً خالی) است. یعنی کرنل لینوکس در کمال سلامت بوده.

تاریخچه دستورات ترمینال رو هم چک کردیم (history) و هیچ دستور خاموشی‌ای در زمان قطعی پیدا نشد.

با کنار هم گذاشتن این پازل‌ها (لایه سخت‌افزار + لایه سیستم‌عامل + لایه پلتفرم + لایه اپلیکیشن)، ما یک پرونده قطعی ساختیم.


نتیجه این T-Shoot:
به جای اینکه با پشتیبانی سرِ اینکه "کی مقصره" دعوا کنیم، مدارک فنی رو کوبیدیم روی میز! بهشون ثابت کردیم که سیستم‌عامل، داکر و دیتابیس ما همگی گزارش یک قطعی ناگهانی برق یا Force Stop از سمت هایپروایزرِ اون‌ها رو دادن.

@codehalics | کدهالیک
  • ❤ 20
  • 👍 5
More from @codehalics
  1. Oct 7, 2026توی نسخه جدید 16.4 نکس‌جی‌اس، مهم‌ترین خبر اینه که مدل جدید Cache Components بالاخره کامل…
  2. Oct 5, 2026یه اتفاق جالب افتاده: یه برنامه‌‌نویس موقع ساخت پروژه دات‌نت با Claude متوجه شده هوش مصنوع…
  3. Oct 5, 2026دوره جامع معماری نرم‌افزار منتشر شد. در این آموزش ۴ ساعته و فشرده، مباحث Clean Architectur…
  4. Oct 4, 2026این پروژه خیلی جالب بود یه نفر نرم افزار مدیریت انبار رو از یه کار خشک و تکراری به یه بازی…
  5. Oct 4, 2026سلام دوستان موسسه فرا رو آماده استخدام یک نیروی کارآموز حضوری در تهران برای پوزیشن فرانت ا…
  6. Oct 3, 2026امروز سرور کدهالیک یه مدت از دسترس خارج شد. بعد از پیگیری معلوم شد هیت‌سینک سرور مشکل داشت…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →