وقتی یک سرور لینوکسی را Boot می‌کنیم، اولین Process سیستم چیست و چه کسی مسئول زنده نگه داشتن سرویس‌هاست؟

در لینوکس، Process با PID 1 نقش ویژه‌ای دارد. این Process بعد از Kernel اجرا می‌شود و مسئولیت‌هایی مثل راه‌اندازی User Space، مدیریت برخی Processهای orphan شده و واکنش به وضعیت سرویس‌های سیستم را بر عهده دارد. در سیستم‌های قدیمی‌تر، این نقش معمولاً توسط init و پیاده‌سازی‌هایی مثل SysVinit انجام می‌شد.

در SysVinit، سرویس‌ها عمدتاً با اسکریپت‌های موجود در مسیرهایی مثل /etc/init.d/ مدیریت می‌شدند و ترتیب اجرای آن‌ها با Runlevelها و لینک‌های مختلف مشخص می‌شد. این مدل ساده و قابل فهم بود، اما با بزرگ‌تر شدن سیستم‌ها، مدیریت dependencyها، اجرای موازی سرویس‌ها و تشخیص وضعیت واقعی سرویس‌ها می‌توانست پیچیده شود.

اینجاست که systemd وارد می‌شود. systemd علاوه بر اینکه PID 1 است، یک سیستم مدیریت سرویس و dependency هم ارائه می‌کند. سرویس‌ها در قالب Unit تعریف می‌شوند؛ مثلاً یک فایل nginx.service می‌تواند مشخص کند سرویس چگونه اجرا شود، به چه سرویس‌هایی وابسته باشد، در صورت Crash چه اتفاقی بیفتد و چه زمانی Start شود. ابزارهایی مثل systemctl و journalctl هم مدیریت سرویس و بررسی Logها را ساده‌تر می‌کنند.

برای یک DevOps، تفاوت فقط در دستور systemctl به‌جای service خلاصه نمی‌شود. مفاهیمی مثل dependency graph، socket activation، service supervision، restart policy، targetها و journald باعث می‌شوند systemd عملاً بخشی از معماری Runtime یک Linux Server باشد. به همین دلیل وقتی یک سرویس روی سرور بالا نمی‌آید، فهمیدن اینکه PID 1 چه نقشی دارد و systemd دقیقاً چه تصمیمی گرفته، می‌تواند بخش مهمی از فرآیند Troubleshooting باشد.

حالا سؤال جالب این است: اگر قرار بود امروز یک سیستم‌عامل Unix/Linux جدید طراحی کنید، برای PID 1 همچنان یک init ساده انتخاب می‌کردید یا چیزی شبیه systemd؟

@things_to_know_channel