این دستور رو تست کنید: kill -9 1924
چرا آخه؟ این چه توصیهٔ بدیه؟ چرا حالا -9؟ ۹۰٪ احتمال داره با زدن این دستور، دبگه توزیع بالا نیاد!
البته فکر کنم ۹۰٪ زیادی باشه. احتمالش کمتره.
چرا؟؟ مگه چی کار می کنه؟
هر برنامه که توی سیستم اجرا میشه، یه pid از طرف کرنل می‌گیره. pid 1 اولین پردازشی هست که کرنل اجرا کرده. توی اکثر سیستم‌ها، systemd این پردازش هست. البته معمولا اولین فایلی که کرنل از محیط کاربر (userspace) اجرا میکنه، فایل init توی روتِ initramfs هست که بعد از بالا اومدن سیستم، init system جایگزینش میشه.
خود کرنل هم چندین پردازش داره، تا حالا ندیدم pid اونها بیشتر از 1000 باشه. توی خروجی ps و بقیه دستورات میشه راحت تشخیصشون داد چون اسمشون بین [] نمایش داده میشه، اسم‌های عجیبی هم دارند، مثلا [kworker/1:0].
اینها رو نمیشه به همین راحتی متوقف کرد چون وظایف مهمی انجام میدند، مثل زمان بندی پردازش‌ها یا اجرای پردازش به صورت موازی و چیز‌های پایه مربوط به سخت‌افزار.
بارگذاری ماژول‌های مختلف می‌تونه باعث اضافه شدن به این پردازش‌ها بشه.
اگه یه برنامه متوقف بشه و بعد دوباره اجرا بشه، ممکنه یه pid دیگه بگیره. مثلا ممکنه فایرفاکس باز و pid اون 47894 باشه و بعد از بستن و باز کردن مجدد، pid اون بشه 37504. در واقعیت کم پیش میاد یه برنامه دوبار اجرا بشه و هر دوباره یه pid بگیره.
دستور kill برای متوقف کردن پردازش‌ها استفاده میشه. با دادن pid پردازش مورد نظر به دستور kill میشه اون رو متوقف کرد، اگه دسترسی لازم رو داشته باشید. اگه دسترسی متوقف کردن پردازش رو نداشته باشید، خطا می‌گیرید.
سیگنال‌های مختلفی هست که میشه به پردازش‌ها داد. با kill -l می‌تونید اونها رو ببینید. این سیگنال‌ها موقع کامپایل کرنل تنظیم میشن. هر کدوم از سیگنال‌ها یه شماره هم داره.
سیگنال SIGTERM باعث میشه پردازش کار‌های مربوط به بسته شدن رو انجام بده و در نهایت بسته بشه. البته پردازش می‌تونه این سیگنال رو نادیده بگیره و به کار خودش ادامه بده. شماره این سیگنال ۱۵ هست.
سیگنال SIGKILL باعث میشه همون موقع پردازش متوقف بشه. اجباری هم هست. معمولا نباید همون اول کار از این سیگنال استفاده کرد. اگه یه پردازش باید قبل از بسته شدن کار خاصی انجام بده، این سیگنال این اجازه رو بهش نمیده. وقتی که این سیگنال به یه پردازش فرستاده میشه، اون پردازش همون موقع متوقف میشه.
شماره این سیگنال ۹ هست.
البته برای pid 1 قضیه یکمی متفاوته. و sudo kill -9 1 معمولا باعث متوقف شدن init system نمیشه.
اگه سیگنال رو برای kill مشخص نکنید، به طور پیش‌فرض از SIGTERM استفاده میکنه. سیگنال رو میشه از طریق شماره اون و همینطور اسمش برای دستور kill مشخص کرد. برای اینکار باید شماره یا اسم سیگنال رو به عنوان یه آپشن کوتاه به دستور kill داد. مثلا اینجوری:
kill -15 1924
kill -SIGTERM 1924دوتا دستور بالا معادل هم هستند. kill 1924 هم معادل دستورات بالا هست. اگه سیگنالی مشخص نشه، kill به طور پیش‌فرض سیگنال SIGTERM می‌فرسته.
دستورات بالا باعث میشه که پردازش 1924 متوقف بشه. البته پردازش می‌تونه اون رو نادیده بگیره و به کار خودش ادامه بده.
این دستورات معادل هم هستند و باعث میشه پردازش، همون موقع که سیگنال رو دریافت میکنه متوقف بشه:
kill -9 1924
kill -SIGKILL 1924 اینها نباید همون اول برای متوقف کردن پردازش‌ها استفاده بشن چون ممکنه پردازش وسط کار مهمی باشه و با اینکار یه مشکلی پیش بیاد.
در مورد مشکل این موضوع، packagekit داشته لیست مخازن رو بروزرسانی می‌کرده.
packagekit یه رابط برای مدیربسته‌های مختلف هست. اینجوری برنامه‌های مختلف و همینطور فروشگاه‌های برنامه (مثل gnome software center یا discover) می‌تونند برنامه‌ها رو از مخارن نصب کنند بدون اینکه لازم باشه پشتیبانی از یه مدیربسته خاص، مستقیم به برنامه اضافه بشه.
توی این مورد، در اصل packagit داشته چیزی شبیه apt update رو انجام میداده.
وقتی که یه چیزی داره با APT یا dpkg کار میکنه، یه فایل lock (یا ممکنه چنتا) قفل میشه تا اگه یه پردازش دیگه‌ای از APT یا dpkg خواست همون کار‌ها رو انجام بده، متوجه بشه.
محل ذخیره این فایل‌های lock بستگی به این داره که از کدوم قابلیت APT یا dpkg داره استفاده میشه. گرفتن اطلاعات در مورد بسته‌ها و اینجور کار‌ها باعث قفل شدن فایل‌های lock نمیشه.
کار‌هایی مثل بروزرسانی لیست مخازن، نصب و ارتقا یا حذف بسته‌ها باعث قفل شدن فایل‌های lock توسط APT یا dpkg میشه. مثلا موقعی که داره لیست مخازن بروزرسانی میشه، این فایل lock قفل میشه.
/var/lib/apt/list/lockبه این دلیل فایل‌های lock قفل میشن تا همزمان دوتا عملیات که ممکنه با هم تداخل داشته باشند، انجام نشه.
تا وقتی یه فایل lock قفله، یه پردازش دیگه از APT یا dpkg کاری که اون فایل lock بهش مربوط هست رو انجام نمیده.
مثلا اگه یه ترمینال باز کنید، sudo apt update رو بزنید و بعد توی یه ترمینال دیگه دوباره این دستور رو امتحان کنید، توی دومی خطا می‌گیرید. تا زمانی که اولی به اتمام نرسه (و فایل lock باز نشه) یه پردازش دیگه از APT لیست مخازن رو بروزرسانی نمی‌کنه.
فایل‌های lock فایل‌هایی خالی هستند. هیچی داخل اونها نیست. حتی وقتی هم قفل میشن، چیزی داخل اونها نوشته نمیشه.
وقتی یه فایل lock قفله، اگه یه پردازش دیگه بخواهد اون فایل رو باز کنه، متوجه میشه توسط یه پردازش دیگه با یه pid دیگه قفل شده.
اگه هر پردازشی به هر دلیلی متوقف بشه، (کلا بسته بشه) فایل‌هایی هم که باز کرده بسته میشن. در نتیجه اگه یه پردازش یکی از اون فایل‌های lock رو قفل کرده باشه ولی بعد متوقف بشه یا به پایان برسه اون فایل lock هم باز میشه.
اون دستور (kill -9 1924) پردازش 1924 رو همون موقع متوقف کرده. توی اون زمان، این پردازش مربوط به packagekit بوده. با اینکار فایل lock باز شده و پردازش‌های دیگه APT، می‌تونستند لیست مخازن رو بروزرسانی کنند.
بهتر بوده از kill 1924 استفاده میشده تا سیگنال SIGTERM فرستاده بشه. اینجوری اگه packagekit لازم میدیده که متوقف نشه، این اتفاق نمی‌افتاده.
ممکنه packagekit در حال نصب، حذف یا بروزرسانی بسته‌ها باشه. در این حالت نباید اون رو متوقف کرد چون باعث میشه اون عملیات وسط کار، متوقف بشه. در این حالت بسته‌ها درست نصب، حذف یا بروزرسانی نشدن و باعث میشه مدیربسته توی حالت خرابی قرار بگیره. معمولا در این حالت apt install -f یا dpkg --configure -a می‌تونه مشکل رو حل کنه.
ولی وضعیتی رو در نظر بگیرید که یکی از بسته‌های مهم مثل خود dpkg یا apt یا coreutils خراب شده باشند. در این حالت بعیده dpkg به همین راحتی وضعیت رو درست کنه.
ممکنه وضعیت بدتر هم باشه، اگه libc خراب بشه. در این حالت تقریبا همه برنامه‌ها با مشکل مواجه میشن. از خود bash تا دستورات ساده‌ای مثل rm یا mv. حتی init system هم ممکنه با مشکل مواجه بشه و کلا initramfs نتونه init system اصلی رو راه‌اندازی کنه. در این حالت یه پوسته اضطراری باز میشه ولی بعیده کاربر بتونه از طریق اون کار خاصی انجام بده.
جدا ازین موضوعات بنظرم کاش یک قابلیت توی انجمن بود که توی هر تاپیک ایجاد کننده تاپیک بتونه جواب درست رو علامت بزنه و این جواب های درست توی پروفایل کاربر پاسخ دهنده ذخیره بشه و به نسبت زمانی که توی انجمن فعالیت داشته و پست هایی که گذاشته و جواب های درستش، یک درصدی زیر اسمش بیاد که کاربر بدونه طرف مقابل تخصصی داره یا نه.
البته قصد توهین به شخص خاصی رو ندارم، ولی بالاخره ممکن بود به قیمت بالا نیومدن سیستم عامل تموم بشه.
انجمن شبیه stackoverflow یا askubuntu نیست. اینجا ممکنه یه رشته ارسال، کاربر رو به جواب برسونه. ممکنه چندین نفر کمک کنند تا مشکل حل بشه. توی askubuntu و stackoverflow معمولا اینجوری نیست.
موضوع: عدم آپدیت یا آپگرید از طریق دستورات در کنسول(حل شد) (دفعات بازدید: 1386 بار)
