systemd چیست؟ مدیر راه‌اندازی و سرویس در لینوکس مدرن

روی تقریباً همهٔ توزیع‌های سروری رایج امروز، اولین فرایندی که پس از هسته کاربرفضا را جمع می‌کند systemd است. اگر nginx بعد از ریبوت بالا نمی‌آید، اگر تایمر بکاپ کار نمی‌کند، یا اگر وابستگی «اول شبکه، بعد اپ» به‌هم ریخته، معمولاً با مدل unit و target سر و کار دارید — نه با اسکریپت‌های پراکندهٔ /etc/init.d به‌تنهایی.

این مقاله نقشهٔ مفهومی است: systemd چه چیزی هست و چه چیزی نیست، واحد (unit) چیست، target چگونه شبیه runlevel عمل می‌کند، و چرا journal به همین اکوسیستم وصل است. فرمان‌های روزمره در مقالهٔ systemctl و لاگ در journalctl عمیق‌تر می‌شوند.

پاسخ کوتاه

systemd یک سامانهٔ init و مدیر سرویس است: واحدهای اعلانی (فایل‌های unit) را می‌خواند، وابستگی‌ها را حل می‌کند، سرویس‌ها را موازی یا به‌ترتیب لازم بالا می‌آورد، وضعیت را پایش می‌کند و با journald لاگ ساخت‌یافته نگه می‌دارد. جایگزین کلاسیک SysV init است، ولی خیلی بیش از «یک اسکریپت استارت» است: سوکت‌اکتیویشن، تایمر، mount، و cgroup برای حسابرسی منابع هم در همین مدل جا می‌گیرند.

systemd را به‌عنوان «سیاست راه‌اندازی و چرخهٔ عمر سرویس» ببینید، نه فقط دکمهٔ start/stop.

چه مشکلی را حل کرد؟

مدل قدیمی init اغلب دنباله‌ای شکننده از اسکریپت‌های شل بود: ترتیب دستی، وضعیت مبهم، و پارس دشوار لاگ. با پیچیده‌تر شدن سرورها — چند سرویس، وابستگی به شبکه و mount، نیاز به restart خودکار — به مدلی نیاز بود که:

• وابستگی را صریح اعلام کند (After=, Requires=, Wants=).
• وضعیت فعال/شکست را یکدست گزارش دهد.
• راه‌اندازی موازی امن‌تری فراهم کند.
• لاگ و سرویس را در یک اکوسیستم نگه دارد.

systemd این‌ها را با فایل‌های unit و یک daemon مرکزی انجام می‌دهد. بحث‌های تاریخی دربارهٔ پیچیدگی و دامنهٔ پروژه وجود دارد؛ در عمل، برای اوبونتو، دبیان، فدورا و RHEL این استاندارد عملیاتی است.

PID 1 و مسئولیت

فرایند init با PID 1 باید یتیمان را adopt کند، سیگنال‌های ویژه را درست مدیریت کند و در صورت سقوط، سیستم را در وضعیت نامشخص نگذارد. systemd به‌عنوان PID 1 این نقش را دارد و سپس بقیهٔ واحدها را فعال می‌کند تا به target پیش‌فرض (اغلب multi-user.target یا graphical.target) برسد.

bash

ps -p 1 -o pid,cmd systemctl get-default

واحد (unit): واحد کار systemd

هر unit یک نام و نوع دارد؛ پسوند نوع را مشخص می‌کند:

فایل‌های واحد معمولاً در /usr/lib/systemd/system/ (بسته) و /etc/systemd/system/ (سفارشی‌سازی محلی با اولویت) قرار دارند. برای override امن از `systemctl edit` استفاده می‌شود تا drop-in بسازید.

bash

systemctl cat ssh.service ls /etc/systemd/system/*.wants 2>/dev/null | head

service به زبان ساده

یک unit از نوع service حداقل می‌گوید چه فرمانی شروع شود و چگونه متوقف شود. بخش‌های رایج:

ini

[Unit] Description=Example API After=network-online.target Wants=network-online.target [Service] Type=simple ExecStart=/usr/local/bin/myapi Restart=on-failure [Install] WantedBy=multi-user.target

Type= رفتار همگام‌سازی آماده‌بودن را عوض می‌کند (simple، forking، notify، …). Restart= سیاست برگشت پس از خروج را می‌سازد — همان دلیلی که kill دستی گاهی بی‌فایده است.

target به‌جای runlevel

به‌جای runlevel عددی، به target می‌رسید: multi-user.target محیط چندکاربرهٔ متنی سرور، graphical.target محیط گرافیکی. فعال کردن یک سرویس برای بوت معمولاً یعنی آن را WantedBy آن target کنید (enable).

bash

systemctl list-units --type=target systemctl isolate multi-user.target # احتیاط: جلسهٔ گرافیکی را می‌بندد

وابستگی و ترتیب

Wants= وابستگی ضعیف («خوب است باشد»)، Requires= قوی‌تر («بدون آن شکست»). After=/Before= ترتیب را مشخص می‌کنند بدون اینکه لزوماً الزام وجود بسازند. اشتباه رایج: فقط After= نوشتن و فرض کردن که سرویس دیگر حتماً موفق شده است.

برای عیب‌یابی زنجیره:

bash

systemctl list-dependencies nginx.service systemctl list-dependencies --reverse nginx.service

سوکت‌اکتیویشن و تایمر — فراتر از سرویس همیشه روشن

با .socket می‌توانید سرویس را هنگام اولین اتصال بیدار کنید (الگوی inetdمانند مدرن). با .timer جایگزین یا مکمل cron برای کارهایی که باید با وضعیت unit هماهنگ باشند می‌سازید. این‌ها نشان می‌دهند systemd فقط «سرویس وب» نیست؛ زمان‌بندی و فعال‌سازی رویدادمحور هم هست.

journal و مشاهده‌پذیری

journald لاگ‌های ساخت‌یافته را جمع می‌کند؛ بسیاری سرویس‌ها stdout/stderr را به journal می‌فرستند. بدون فهم این پیوند، دنبال /var/log/syslog می‌گردید و نیمی از داستان را از دست می‌دهید. جزئیات پرس‌وجو در journalctl است.

systemd چه چیزی نیست؟

• جایگزین کامل مانیتورینگ محصول (uptime بیرونی، APM) نیست.
• ضمانت صحت اپ شما نیست؛ فقط چرخهٔ عمر فرایند را مدیریت می‌کند.
• اجبار به یک توزیع خاص نیست، ولی جزئیات مسیر فایل و نام سرویس‌ها بین توزیع‌ها فرق جزئی دارد.

رابطه با مقالات بعدی

systemctl واسط روزمرهٔ شما برای start/stop/status/enable است. journalctl چشم شما به شکست‌های بوت و سرویس است. بدون این دو، دانش systemd در حد تعریف می‌ماند.

اشتباه‌های رایج مفهومی

• ویرایش مستقیم فایل بسته در /usr/lib به‌جای drop-in در /etc.
• فرض اینکه enable یعنی الان start هم شده (معمولاً جداست).
• نادیده گرفتن Type=forking برای برنامه‌های قدیمی daemonize.
• مقایسهٔ احساسی با SysV بدون معیار: ترتیب، لاگ، restart، وابستگی.

خلاصه

systemd init و مدیر سرویس لینوکس مدرن است: unit اعلانی، target به‌جای runlevel، وابستگی صریح، و پیوند با journal. برای کار عملی، مدل را اینجا بگیرید و دست را با systemctl و journalctl قوی کنید. سرویس سفارشی را با فایل unit نسخه‌پذیر کنید، نه با اسکریپت بدون وضعیت.

سوالات متداول

آیا همهٔ لینوکس‌ها systemd دارند؟

خیر. برخی توزیع‌ها یا محیط‌های خاص init دیگر دارند. ولی در سرورهای ابری رایج اوبونتو/دبیان/RHEL-like، پیش‌فرض systemd است.

فرق service و process چیست؟

process نمونهٔ در حال اجرا در هسته است؛ service واحد مدیریت‌شده‌ای است که ممکن است صفر، یک یا چند process را طبق تعریف unit کنترل کند.

منابع و مراجع

• systemd project: https://systemd.io/
• systemd(1): https://www.freedesktop.org/software/systemd/man/latest/systemd.html
• systemd.unit(5): https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html
• systemd.service(5): https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html