پیامی درباره یک کمکیار که از قبل در حال اجراست را نشانه‌ای از چرخه حیات بدانید، نه اجازه‌ای برای شروع کشتن فرایندها. گام خطرناک خود توقف نیست، بلکه شناسایی پیش از آن است، زیرا ممکن است چند مؤلفه با نامهای مشابه روی یک Mac وجود داشته باشد و تنها یکی از آنها مالک اتصال باشد. نخست سابقه هویت را بسازید. سپس تصمیم بگیرید که آیا توقف به‌کلی اقدام درستی است.

پیش از اقدام، سابقه هویت را بسازید

چهار واقعیت یک فرایند را قابل شناسایی می‌کند: PID کنونی همراه با زمان آغازش، فایل اجرایی و محصولی که به آن تعلق دارد، بافتی کاربری یا دسترسی که زیر آن اجرا می‌شود، و هر چیزی که آن را آغاز کرده است. ps -o pid,ppid,user,etime,command -p 1234 سه مورد نخست را در یک خط به شما می‌دهد، از جمله اینکه فرایند چه مدت زنده بوده است. Activity Monitor همان اطلاعات را با ظاهری دوستانه‌تر نشان می‌دهد. کنترل‌کننده را اضافه کنید، یعنی برنامه یا سرویسی که مسئول آغاز و توقف آن است. با این چهار مورد، فرایند از یک نام بودن دست می‌کشد و به شیئی تبدیل می‌شود که می‌توانید درباره‌اش استدلال کنید.

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

PID در یک گزارش قدیمی اکنون مال کس دیگری است

شناسه‌های فرایند بازیافت می‌شوند و شماره‌ای که از گزارش دیروز کپی شده است ممکن است اکنون به چیزی کاملاً بی‌ربط اشاره کند. پیش از هر نتیجه‌گیری، زمان آغاز را با برچسب زمانی گزارش مقایسه کنید. همین امر درباره نام کوتاه نیز صادق است: دو ساخت از یک محصول می‌توانند کمکیارهایی با نامهای یکسان و اهداف متفاوت عرضه کنند. هویت همان چندتایی است، هرگز تنها شماره نیست.

پیش از دست زدن به هر چیز دیگر، نقشها را جدا کنید. کلاینت یک اتصال، کمکیار مشترکی که به چند برنامه خدمت می‌کند، و سروری که نشستهای دیگران را می‌پذیرد، همه در فهرست مانند یک فرایند پس‌زمینه به نظر می‌رسند. تنها یکی از آنها را می‌توان بدون پیامدهایی که در نظر نگرفته‌اید متوقف کرد.

از راه مالک متوقف کنید، نه از راه سیگنال

با کنترلی شروع کنید که مالک چیز است: دکمه قطع اتصال، فرمان توقف پشتیبانی‌شده سرویس، یا اقدام خود عامل مدیریت. این مسیرها آن برچیدنی را اجرا می‌کنند که محصول انتظار دارد، شامل حذف مسیرها و بستن دستگاه تونل. سیگنال همه اینها را دور می‌زند و وضعیت را پشت سر می‌گذارد.

ببینید پس از آن چه باقی می‌ماند. فرایندی که مقیم می‌ماند ممکن است منتظر اتصال بعدی باشد، که یک انتخاب طراحی است و نه توقفی ناموفق.

چرا یک ناظر آنچه را کشته‌اید دوباره راه‌اندازی می‌کند

اگر یک شبح راه‌انداز یا سیاست اتصال خودکار بخواهد تونل برپا باشد، کشتن فرایند چیزی را بیان نمی‌کند. ناظر خروج را می‌بیند و آن را دوباره آغاز می‌کند، گاهی پیش از آنکه خواندن گزارش را تمام کنید.

پیش از جنگیدن با ناظر، آن را پیدا کنید. launchctl list کارهای بارگذاری‌شده و برچسب‌هایشان را نشان می‌دهد و کاری که تنظیم زنده‌نگه‌داشتن دارد بنا به طراحی در خروج دوباره راه‌اندازی می‌شود. اقدام درست در آنجا تغییر قصد است: کار را تخلیه کنید، سیاست اتصال خودکار را غیرفعال کنید، یا از مدیر سیستم بخواهید این کار را بکند. خروج اجباری ابزاری متفاوت با معنایی متفاوت است و به رویه بازیابی مستند برای فرایندی گیرکرده تعلق دارد، نه به مدیریت روزمره اتصال.

رویداد چرخه حیات را ثبت کنید، نه کشتن را

هویت مؤلفه، نسخه کلاینت، نخستین رویداد مرتبط چرخه حیات و کاری که کردید را بنویسید. رویداد مهم‌تر از اقدام است، زیرا دو نمونه که هنگام ورود ظاهر می‌شوند یک مشکل ترتیب راه‌اندازی است که تکرار خواهد شد. سابقه‌ای که فایل اجرایی و کنترل‌کننده آن را نام می‌برد به نفر بعدی امکان بازتولید آن را می‌دهد.

سپس وضعیت موردنظر را بررسی کنید: سرویسی که کاربر نیاز داشت و منبع خصوصی‌ای که به آن می‌رسد. از خط لوله‌ای که یک زیررشته را جست‌وجو می‌کند و هر تطابق را به زور می‌کشد بپرهیزید، زیرا همه موارد بالا را دور می‌ریزد و معمولاً شاهد اینکه چرا دو نمونه وجود داشتند را نابود می‌کند. اگر فرایند باز هم برمی‌گردد، یافته یک نقص پیکربندی یا ترتیب است و اصلاح آن به کسی تعلق دارد که مالک رفتار راه‌اندازی کلاینت است.

مقالات مرتبط