systemctl: کنترل سرویس‌ها و واحدهای systemd

بیشتر کار روزمره با systemd از یک فرمان می‌گذرد: systemctl. به‌جای به‌خاطر سپردن مسیر اسکریپت init، نام unit را می‌گویید و وضعیت، شروع، توقف، فعال‌سازی در بوت یا ماسک را درخواست می‌کنید. اشتباه در تفاوت start و enable یکی از پرتکرارترین علت‌های «بعد از ریبوت سرویس نیست» است.

این مقاله جعبه ابزار عملی است؛ مفاهیم unit در مقالهٔ systemd آمده است.

پاسخ کوتاه

`systemctl status` برای دیدن وضعیت و چند خط آخر لاگ، `start`/`stop`/`restart` برای چرخهٔ عمر الان، `enable`/`disable` برای بودن یا نبودن در بوت، `mask` برای جلوگیری قطعی از شروع، و بعد از تغییر فایل unit حتماً `daemon-reload`. روی اوبونتو نام سرویس SSH اغلب `ssh.service` است نه `sshd.service` — همیشه با tab-complete یا list تأیید کنید.

start یعنی الان؛ enable یعنی بعد از بوت — دو کلید جدا، دو اشتباه جدا.

دیدن وضعیت

bash

systemctl status nginx.service systemctl is-active nginx systemctl is-enabled nginx systemctl is-failed nginx

خروجی status معمولاً Active state، Main PID، cgroup و چند خط journal را نشان می‌دهد. برای شکست‌ها:

bash

systemctl --failed systemctl list-units --type=service --state=failed

شروع، توقف، راه‌اندازی مجدد

bash

sudo systemctl start nginx sudo systemctl stop nginx sudo systemctl restart nginx sudo systemctl reload nginx

reload وقتی واحد ExecReload= دارد پیکربندی را بدون قطع کامل بارگذاری می‌کند؛ اگر پشتیبانی نشود خطا می‌گیرید و باید restart کنید. برای اپهایی که اتصال طولانی دارند، پیامد restart را با تیم هماهنگ کنید.

bash

sudo systemctl try-restart nginx sudo systemctl reload-or-restart nginx

enable در برابر start

bash

sudo systemctl enable --now nginx sudo systemctl disable --now nginx

لیست و جستجو

bash

systemctl list-units --type=service systemctl list-unit-files --type=service | grep nginx systemctl list-timers --all

list-units آنچه بارگذاری/فعال است را نشان می‌دهد؛ list-unit-files وضعیت فایل‌ها (enabled/disabled/static/masked) را.

ماسک: جلوگیری قطعی

bash

sudo systemctl mask bluetooth.service sudo systemctl unmask bluetooth.service

mask واحد را به /dev/null پیوند می‌دهد تا حتی start دستی هم شکست بخورد — قوی‌تر از disable. برای سرویس‌هایی که بستهٔ دیگر ناخواسته استارت می‌کند مفید است؛ فراموش کردن unmask بعداً گیج‌کننده است.

ویرایش امن با drop-in

bash

sudo systemctl edit nginx.service

ادیتور یک فایل در /etc/systemd/system/nginx.service.d/override.conf باز می‌کند. بعد از ذخیره:

bash

sudo systemctl daemon-reload sudo systemctl restart nginx systemctl cat nginx.service

daemon-reload یعنی systemd فایل‌ها را دوباره بخواند؛ جایگزین restart خود سرویس نیست. cat واحد ادغام‌شده را نشان می‌دهد.

لاگ سریع از systemctl

bash

journalctl -u nginx.service -e journalctl -u nginx.service -f systemctl status nginx -l --no-pager

کاربر در برابر سیستم

بدون --user روی واحدهای سیستم (معمولاً root) کار می‌کنید. برای سرویس‌های نشست کاربر:

bash

systemctl --user status systemctl --user enable --now myapp.service

مسیر فایل‌ها و journal جداست؛ روی سرور headless بیشتر با واحدهای سیستم سروکار دارید.

عیب‌یابی بوت و وابستگی

bash

systemctl list-dependencies ssh.service systemctl show nginx -p ActiveState -p SubState -p MainPID -p FragmentPath systemctl critical-chain

critical-chain کمک می‌کند ببینید چه چیزی بوت را طولانی کرده؛ برای بهینه‌سازی شروع مفید است نه برای هر حادثهٔ روزانه.

الگوی عملی استقرار یک سرویس

1. فایل unit را در /etc/systemd/system/myapp.service بگذارید.
2. daemon-reload
3. start و status را چک کنید؛ journal را بخوانید.
4. اگر سالم بود enable --now
5. ریبوت آزمایشی یا حداقل stop/start مجدد قبل از ترک سرور.

bash

sudo install -m 644 myapp.service /etc/systemd/system/myapp.service sudo systemctl daemon-reload sudo systemctl enable --now myapp systemctl status myapp --no-pager

اشتباه‌های رایج

• فراموش daemon-reload بعد از ویرایش unit.
• اشتباه گرفتن نام ssh و sshd بین توزیع‌ها.
• restart مکرر به‌جای خواندن لاگ علت کرش.
• disable کردن سرویس حیاتی از راه دور بدون console.
• ویرایش فایل vendor و از دست رفتن تغییر در ارتقای بسته.

خلاصه

systemctl زبان مشترک کنترل سرویس است: وضعیت را ببینید، start/stop را از enable جدا کنید، با edit و daemon-reload سفارشی‌سازی کنید، و برای مسدودسازی قطعی mask را بشناسید. قدم بعدی مسلط شدن به journalctl برای دیدن «چرا» پشت هر failed است.

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

چرا enable کردم ولی بعد از بوت نیست؟

ممکن است واحد failed شده، وابستگی شبکه نبوده، یا mask/conflict داشته. status و journal بعد از بوت را ببینید؛ is-enabled فقط symlink را می‌گوید نه موفقیت اجرا را.

فرق restart و try-restart؟

try-restart فقط اگر فعال باشد راه می‌اندازد مجدد؛ اگر خوابیده باشد بیدارش نمی‌کند.

منابع و مراجع

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