آموزش مشاهده و مدیریت سرویس‌ها در لینوکس با systemctl

مقدمه: 

آموزش مشاهده و مدیریت سرویس‌ها در لینوکس با systemctl برای کنترل سرویس‌هایی مانند SSH، وب‌سرور، دیتابیس، Docker و Fail2ban ضروری است. با این ابزار می‌توان وضعیت سرویس را مشاهده کرد، آن را راه‌اندازی یا متوقف کرد، تنظیماتش را دوباره بارگذاری نمود و اجرای خودکار آن هنگام روشن‌شدن سرور را کنترل کرد. بااین‌حال، توقف سرویس‌های مهمی مانند SSH، شبکه یا فایروال روی سرور راه دور ممکن است دسترسی مدیریتی را قطع کند.

فهرست مطالب

• systemctl و systemd چیست؟
• Unit و Service چه تفاوتی دارند؟
• مشاهده سرویس‌های لینوکس
• بررسی وضعیت یک سرویس
• Start، Stop، Restart و Reload
• Enable و Disable سرویس‌ها
• تفاوت Disable و Mask
• مشاهده فایل و تنظیمات سرویس
• کاربرد daemon-reload
• بررسی گزارش‌ها با journalctl
• عیب‌یابی سرویس‌های Failed
• ساخت Override برای یک سرویس
• چک‌لیست مدیریت امن سرویس‌ها
• جمع‌بندی و سؤالات متداول

systemctl چیست؟

systemctl ابزار خط فرمان مدیریت systemd است. در بسیاری از توزیع‌های جدید لینوکس، systemd راه‌اندازی سیستم، اجرای سرویس‌ها، وابستگی‌ها، Timerها، Mountها و تعدادی دیگر از منابع سیستم را مدیریت می‌کند.

با systemctl می‌توان به systemd فرمان داد که یک Unit را فعال، متوقف، راه‌اندازی مجدد یا بررسی کند. بیشتر کاربران با Unitهای دارای پسوند .service کار می‌کنند، اما systemd فقط محدود به سرویس‌ها نیست.

نمونه‌هایی از Unitهای systemd عبارت‌اند از:

در بیشتر دستورها می‌توان پسوند .service را حذف کرد. برای نمونه، دو دستور زیر معمولاً به یک سرویس اشاره می‌کنند:

systemctl status ssh

systemctl status ssh.service

نام دقیق Unit بین توزیع‌ها و بسته‌ها ممکن است متفاوت باشد. برای مثال، نام سرویس SSH در یک سیستم می‌تواند ssh.service و در سیستم دیگری sshd.service باشد؛ بنابراین پیش از اجرا، نام واقعی را پیدا کنید.

اگر سرویس‌های سرور شما پس از راه‌اندازی مجدد اجرا نمی‌شوند یا مکرراً وارد وضعیت Failed می‌شوند، می‌توانید برای بررسی systemd، وابستگی‌ها و گزارش‌های سیستم از کارشناسان شرکت تجارت الکترونیک نوژن مشاوره فنی دریافت کنید.

تفاوت Unit فعال، در حال اجرا و Enable شده

یکی از خطاهای رایج، یکسان‌دانستن وضعیت Running و Enabled است. این دو مفهوم به زمان‌های متفاوت مربوط می‌شوند.

• Active یا Running: سرویس اکنون در حال اجراست.
• Inactive: سرویس اکنون فعال نیست.
• Failed: سرویس اجرا نشده یا با خطا متوقف شده است.
• Enabled: برای شروع خودکار در شرایط تعریف‌شده، معمولاً هنگام Boot، پیوندهای لازم ایجاد شده‌اند.
• Disabled: سرویس برای شروع خودکار Enable نشده است.
• Masked: راه‌اندازی سرویس عمداً مسدود شده است.

یک سرویس می‌تواند اکنون Running باشد، اما برای Boot بعدی Enabled نباشد. همچنین ممکن است Enabled باشد، اما در لحظه فعلی به‌دلیل خطا اجرا نشود.

مستندات systemd نیز تأکید می‌کنند که Enable با Start یکسان نیست؛ Enable اتصال‌های لازم برای فعال‌سازی آینده را ایجاد می‌کند، اما Start سرویس را در نشست فعلی اجرا می‌کند. freedesktop.org

آموزش مشاهده سرویس‌ها در لینوکس با systemctl

برای مشاهده سرویس‌هایی که systemd اکنون در حافظه دارد، اجرا کنید:

systemctl list-units --type=service

به‌صورت پیش‌فرض، این دستور بیشتر Unitهای فعال، در انتظار یا Failed را نمایش می‌دهد. برای افزودن سرویس‌های غیرفعال:

systemctl list-units --type=service --all

طبق مستندات systemctl، ستون‌های اصلی خروجی عبارت‌اند از:

• UNIT: نام Unit
• LOAD: وضعیت بارگذاری فایل Unit
• ACTIVE: وضعیت کلی
• SUB: وضعیت جزئی‌تر متناسب با نوع Unit
• DESCRIPTION: توضیح سرویس

فرمان list-units فقط تمام فایل‌های نصب‌شده را فهرست نمی‌کند؛ بلکه Unitهایی را نشان می‌دهد که systemd در حافظه دارد. برای مشاهده Unit Fileهای نصب‌شده باید از list-unit-files استفاده کرد. freedesktop.org

مشاهده تمام فایل‌های سرویس نصب‌شده

systemctl list-unit-files --type=service

برای مشاهده فقط سرویس‌های Enabled:

systemctl list-unit-files --type=service --state=enabled

برای مشاهده سرویس‌های Disabled:

systemctl list-unit-files --type=service --state=disabled

جست‌وجوی نام یک سرویس

می‌توانید خروجی را با ابزارهایی مانند grep محدود کنید:

systemctl list-unit-files --type=service | grep nginx

در بسیاری از نسخه‌ها، الگوی مستقیم نیز قابل استفاده است:

systemctl list-unit-files 'nginx*'

قبل از مدیریت یک سرویس، نام دقیق Unit را از همین خروجی پیدا کنید.

مطالعه بیشتر: SSH چیست و چگونه به سرور لینوکس متصل شویم

بررسی وضعیت سرویس با systemctl status

برای مشاهده وضعیت یک سرویس:

sudo systemctl status nginx

این دستور معمولاً اطلاعات زیر را نمایش می‌دهد:

• نام و توضیح Unit
• محل فایل سرویس
• وضعیت Loaded
• وضعیت Active
• زمان شروع یا توقف
• شناسه پردازش اصلی
• بخشی از گزارش‌های اخیر
• نتیجه آخرین اجرا

اگر خروجی در حالت Pager باز شد، با کلید q از آن خارج شوید. برای نمایش بدون Pager:

sudo systemctl --no-pager status nginx

استفاده از status فقط برای سرویس‌های خراب نیست. پیش از Restart یا تغییر تنظیمات نیز وضعیت سرویس را ثبت کنید تا بتوانید حالت قبل و بعد را مقایسه کنید.

بررسی سریع فعال‌بودن سرویس

systemctl is-active nginx

خروجی می‌تواند active، inactive، failed یا وضعیت دیگری باشد. این فرمان برای اسکریپت‌ها نیز مناسب است، زیرا علاوه بر متن خروجی، کد خروج وضعیت ارائه می‌کند.

برای استفاده در شرط Shell:

if systemctl is-active --quiet nginx; then
    echo "Service is active"
else
    echo "Service is not active"
fi

متن پیام نمونه است و می‌تواند متناسب با اسکریپت تغییر کند.

بررسی Enable بودن سرویس

systemctl is-enabled nginx

نتیجه ممکن است enabled، disabled، static، masked یا حالت دیگری باشد. وضعیت static الزاماً خطا نیست؛ چنین Unitی ممکن است توسط وابستگی، Socket یا Unit دیگری فعال شود و بخش نصب لازم برای Enable مستقل را نداشته باشد. freedesktop.org

دستورات Start، Stop، Restart و Reload

جدول زیر مهم‌ترین عملیات روزمره را مقایسه می‌کند:

برای مشاهده سرویس‌های سرور مجازی، انتخاب سیستم‌عامل و دریافت خدمات مدیریت زیرساخت می‌توانید راهکارهای شرکت تجارت الکترونیک نوژن را بررسی کنید. سطح مدیریت موردنیاز به تجربه تیم شما در systemd، شبکه و امنیت لینوکس بستگی دارد.

مطالعه بیشتر: خرید سرور مجازی لینوکس

راه‌اندازی سرویس

sudo systemctl start nginx

سپس وضعیت را بررسی کنید:

sudo systemctl status nginx

Start فقط سرویس را در وضعیت فعلی سیستم اجرا می‌کند و به‌تنهایی تضمین نمی‌کند که سرویس پس از Reboot نیز فعال شود.

توقف سرویس

sudo systemctl stop nginx

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

راه‌اندازی مجدد

sudo systemctl restart nginx

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

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

بارگذاری مجدد تنظیمات

sudo systemctl reload nginx

Reload برای سرویس‌هایی کاربرد دارد که قابلیت دریافت مجدد تنظیمات بدون Restart کامل را فراهم کرده‌اند. اگر سرویس Reload را پشتیبانی نکند، فرمان با خطا مواجه می‌شود.

گزینه جایگزین:

sudo systemctl reload-or-restart nginx

این دستور در صورت امکان Reload انجام می‌دهد و در غیر این صورت ممکن است سرویس را Restart کند. چون Restart می‌تواند وقفه ایجاد کند، قبل از استفاده رفتار آن را در سرویس موردنظر بررسی کنید.

Enable و Disable سرویس‌ها

برای فعال‌کردن شروع خودکار سرویس:

sudo systemctl enable nginx

این دستور سرویس را لزوماً همان لحظه Start نمی‌کند. برای Enable و Start هم‌زمان:

sudo systemctl enable --now nginx

برای حذف شروع خودکار:

sudo systemctl disable nginx

Disable نیز سرویس در حال اجرا را لزوماً Stop نمی‌کند. برای Disable و Stop هم‌زمان:

sudo systemctl disable --now nginx

مستندات systemctl بیان می‌کنند که Enable پیوندهای تعریف‌شده در بخش [Install] را ایجاد می‌کند، درحالی‌که Disable این پیوندها را حذف می‌کند. Disable به‌خودی‌خود به معنای توقف سرویس فعال نیست. freedesktop.org

جدول تصمیم‌گیری Start و Enable

تفاوت Disable و Mask

Disable فقط پیوندهای Enable را حذف می‌کند. در این وضعیت ممکن است سرویس همچنان به‌صورت دستی، از طریق وابستگی یا توسط Unit دیگری فعال شود.

Mask محدودیت شدیدتری ایجاد می‌کند:

sudo systemctl mask SERVICE

در این حالت Unit معمولاً به /dev/null پیوند داده می‌شود و تلاش برای Start آن شکست می‌خورد. مستندات systemd نیز Mask را نسخه قوی‌تر Disable معرفی می‌کنند و درباره استفاده محتاطانه از آن هشدار می‌دهند. freedesktop.org

برای برداشتن Mask:

sudo systemctl unmask SERVICE

سپس در صورت نیاز سرویس را Start یا Enable کنید:

sudo systemctl start SERVICE

سرویس‌های حیاتی را فقط زمانی Mask کنید که وابستگی‌ها و پیامدهای توقف آن‌ها را می‌شناسید.

مشاهده سرویس‌های Failed

برای نمایش Unitهای Failed:

systemctl --failed

یا فقط سرویس‌های Failed:

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

وضعیت Failed می‌تواند در اثر خروج برنامه با کد خطا، Crash، Timeout، تنظیمات نامعتبر یا تکرار بیش‌ازحد راه‌اندازی ایجاد شود. freedesktop.org

پس از رفع علت خطا، سرویس را Restart کنید:

sudo systemctl restart SERVICE

برای پاک‌کردن وضعیت Failed ثبت‌شده:

sudo systemctl reset-failed SERVICE

reset-failed مشکل سرویس را برطرف نمی‌کند؛ فقط وضعیت شکست ثبت‌شده و برخی شمارنده‌های مرتبط را بازنشانی می‌کند. ابتدا باید علت اصلی را از گزارش‌ها و تنظیمات پیدا کنید.

مشاهده فایل و تنظیمات Unit

برای مشاهده فایل اصلی Unit و Drop-inهای مرتبط:

systemctl cat nginx

برای دیدن مسیر Fragment اصلی:

systemctl show -p FragmentPath nginx

برای مشاهده تمام Propertyهای Unit:

systemctl show nginx

خروجی show برای پردازش ماشینی و عیب‌یابی دقیق مناسب‌تر از status است. برای نمایش یک Property خاص:

systemctl show -p MainPID nginx

یا:

systemctl show -p ActiveState -p SubState nginx

فایل‌های متعلق به بسته را مستقیماً در مسیرهای سیستمی ویرایش نکنید؛ زیرا ممکن است هنگام به‌روزرسانی جایگزین شوند. برای تغییر تنظیمات systemd بهتر است از Drop-in استفاده شود.

ساخت Override با systemctl edit

برای ایجاد تنظیمات تکمیلی یک سرویس:

sudo systemctl edit nginx

این فرمان معمولاً یک فایل Drop-in در ساختاری شبیه مسیر زیر ایجاد می‌کند:

/etc/systemd/system/nginx.service.d/override.conf

داخل Override فقط گزینه‌هایی را قرار دهید که واقعاً باید تغییر کنند. ساختار گزینه‌ها به نوع Unit و نیاز سرویس بستگی دارد.

پس از ذخیره Override، معمولاً باید تنظیمات مدیر systemd دوباره خوانده شوند:

sudo systemctl daemon-reload

سپس سرویس را در صورت نیاز Restart کنید:

sudo systemctl restart nginx

قبل از اعمال Override روی سرویس حیاتی، فایل فعلی را با systemctl cat بررسی کنید و راه بازگشت داشته باشید.

daemon-reload چه کاری انجام می‌دهد؟

فرمان زیر فایل‌های Unit و وابستگی‌های systemd را دوباره بارگذاری می‌کند:

sudo systemctl daemon-reload

این فرمان با Reload کردن خود سرویس متفاوت است:

• systemctl daemon-reload تغییرات فایل‌های Unit را به systemd معرفی می‌کند.
• systemctl reload SERVICE از خود برنامه می‌خواهد تنظیمات برنامه را دوباره بخواند.
• systemctl restart SERVICE پردازش سرویس را از نو اجرا می‌کند.

اگر فقط فایل تنظیمات Nginx، پایگاه داده یا برنامه را تغییر داده‌اید، daemon-reload الزاماً لازم نیست. این فرمان بیشتر زمانی کاربرد دارد که Unit File، Drop-in یا ساختار وابستگی systemd تغییر کرده باشد.

مشاهده وابستگی‌های سرویس

برای نمایش وابستگی‌های یک Unit:

systemctl list-dependencies nginx

برای نمایش وابستگی معکوس، یعنی Unitهایی که به سرویس موردنظر وابسته‌اند:

systemctl list-dependencies --reverse nginx

این بررسی پیش از Stop، Disable یا Mask کردن یک سرویس اهمیت دارد. ممکن است یک Unit ظاهراً مستقل، پیش‌نیاز چند سرویس دیگر باشد.

برای مشاهده علت احتمالی فعال‌شدن خودکار یک سرویس، Socketها، Timerها، Pathها و وابستگی‌های آن را نیز بررسی کنید.

مشاهده گزارش سرویس با journalctl

خروجی systemctl status فقط بخشی از گزارش‌های اخیر را نشان می‌دهد. برای بررسی کامل‌تر یک Unit از journalctl استفاده کنید:

sudo journalctl -u nginx

مشاهده گزارش از Boot فعلی:

sudo journalctl -u nginx -b

نمایش آخرین خطوط:

sudo journalctl -u nginx -n 100

دنبال‌کردن گزارش‌ها به‌صورت زنده:

sudo journalctl -u nginx -f

نمایش گزارش از زمان مشخص:

sudo journalctl -u nginx --since "30 minutes ago"

برای خروج از حالت دنبال‌کردن زنده، کلیدهای Ctrl+C را فشار دهید.

گزارش‌ها ممکن است حاوی IP، مسیر فایل، نام کاربری یا اطلاعات فنی حساس باشند. پیش از ارسال آن‌ها برای دیگران، داده‌های محرمانه را حذف کنید.

مطالعه بیشتر: نصب و تنظیم Fail2ban برای محافظت از SSH

روش اصولی عیب‌یابی سرویس Failed

هنگامی که یک سرویس اجرا نمی‌شود، تغییرات تصادفی یا Restart مکرر معمولاً کمکی نمی‌کند. مراحل زیر را به‌ترتیب انجام دهید.

مرحله اول: مشاهده وضعیت

sudo systemctl status SERVICE --no-pager

به پیام خطا، کد خروج، زمان شکست و مسیر Unit توجه کنید.

مرحله دوم: مشاهده گزارش کامل‌تر

sudo journalctl -u SERVICE -b -n 100 --no-pager

اگر خطا هنگام Boot رخ داده باشد، گزارش Boot فعلی اهمیت بیشتری دارد.

مرحله سوم: بررسی فایل Unit

systemctl cat SERVICE

Overrideها، مسیر ExecStart، کاربر اجراکننده و وابستگی‌ها را بررسی کنید.

مرحله چهارم: آزمایش تنظیمات خود برنامه

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

مرحله پنجم: بررسی فایل و Permission

مسیر فایل اجرایی، فایل تنظیمات و پوشه‌های موردنیاز را بررسی کنید:

ls -l /path/to/file

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

مرحله ششم: Restart و بررسی مجدد

پس از رفع خطا:

sudo systemctl restart SERVICE
sudo systemctl status SERVICE --no-pager

اگر وضعیت سالم شد، عملکرد واقعی سرویس را نیز آزمایش کنید. Active بودن پردازش همیشه به معنای درست‌بودن پاسخ برنامه یا دسترسی شبکه نیست.

مطالعه بیشتر: دستورات chmod و chown در لینوکس

سناریوی عملی: مدیریت یک وب‌سرور

فرض کنید پس از تغییر فایل تنظیمات وب‌سرور می‌خواهید سرویس را به‌شکل ایمن بارگذاری کنید.

ابتدا وضعیت فعلی را بررسی کنید:

sudo systemctl status nginx --no-pager

سپس با ابزار خود Nginx صحت پیکربندی را آزمایش کنید:

sudo nginx -t

اگر آزمایش موفق بود، تنظیمات را Reload کنید:

sudo systemctl reload nginx

در پایان وضعیت و گزارش‌های جدید را ببینید:

sudo systemctl status nginx --no-pager
sudo journalctl -u nginx -n 30 --no-pager

اگر نرم‌افزار دیگری استفاده می‌کنید، فرمان آزمایش و نام Unit را با همان سرویس تطبیق دهید.

اشتباهات رایج در مدیریت سرویس‌ها

Restart بدون بررسی تنظیمات

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

اشتباه‌گرفتن Enable با Start

Enable برای شروع خودکار آینده است و لزوماً سرویس را اکنون اجرا نمی‌کند. برای انجام هر دو عملیات از enable --now استفاده کنید.

Disable کردن و انتظار Stop فوری

Disable شروع خودکار را حذف می‌کند، اما سرویس فعال ممکن است همچنان اجرا شود. در صورت نیاز و پس از بررسی از disable --now استفاده کنید.

Mask کردن سرویس بدون بررسی وابستگی

Mask تمام تلاش‌های معمول برای راه‌اندازی Unit را مسدود می‌کند. این کار می‌تواند سرویس‌های وابسته را نیز مختل کند.

ویرایش مستقیم Unit اصلی

فایل‌های متعلق به بسته ممکن است در به‌روزرسانی بعدی جایگزین شوند. برای تغییرات محلی از systemctl edit و Drop-in استفاده کنید.

توقف SSH روی سرور راه دور

اگر فقط از طریق SSH به سرور دسترسی دارید، Stop یا Mask کردن سرویس SSH می‌تواند اتصال مجدد را ناممکن کند. پیش از تغییر، نشست فعال و کنسول اضطراری ارائه‌دهنده را در دسترس نگه دارید.

مطالعه بیشتر: آموزش ساخت User و دادن دسترسی Sudo در Ubuntu

مطالعه بیشتر: امنیت سرور لینوکس بعد از راه‌اندازی

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

• نام دقیق Unit پیدا شده است.
• وضعیت فعلی با systemctl status ثبت شده است.
• فایل Unit و Overrideها با systemctl cat بررسی شده‌اند.
• وابستگی‌ها پیش از Stop یا Mask بررسی شده‌اند.
• فایل تنظیمات برنامه پیش از Restart آزمایش شده است.
• برای سرویس راه دور، دسترسی کنسول اضطراری وجود دارد.
• تفاوت Start و Enable در نظر گرفته شده است.
• از Mask فقط در صورت ضرورت استفاده شده است.
• پس از تغییر Unit، daemon-reload اجرا شده است.
• گزارش سرویس با journalctl بررسی شده است.
• پس از راه‌اندازی، عملکرد واقعی برنامه آزمایش شده است.
• اطلاعات حساس پیش از اشتراک‌گذاری Log حذف شده‌اند.

جمع‌ بندی

در آموزش مشاهده و مدیریت سرویس‌ها در لینوکس با systemctl یاد گرفتیم که status برای بررسی وضعیت، start و stop برای کنترل اجرای فعلی و enable و disable برای مدیریت فعال‌سازی آینده استفاده می‌شوند. Running بودن یک سرویس با Enabled بودن آن یکسان نیست.

برای تغییر فایل‌های Unit بهتر است از systemctl edit استفاده کنید و پس از آن daemon-reload را اجرا نمایید. در مقابل، Reload یک سرویس به معنای درخواست از همان برنامه برای خواندن مجدد تنظیمات است.

هنگام بروز خطا، ابتدا systemctl status و سپس گزارش‌های journalctl را بررسی کنید. Restart مکرر بدون شناخت علت، ممکن است پیام اصلی خطا را پنهان کند یا باعث وقفه بیشتر شود.

اگر برای عیب‌یابی سرویس‌های Failed، تنظیم systemd یا مدیریت سرور لینوکس به پشتیبانی نیاز دارید، می‌توانید با شرکت تجارت الکترونیک نوژن تماس بگیرید و خدمات سرور مجازی و زیرساخت را متناسب با نیاز پروژه بررسی کنید.

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

چگونه فهرست سرویس‌های لینوکس را مشاهده کنیم؟

از systemctl list-units --type=service برای سرویس‌های موجود در حافظه و از systemctl list-unit-files --type=service برای فایل‌های سرویس نصب‌شده استفاده کنید.

تفاوت systemctl start و enable چیست؟

start سرویس را اکنون اجرا می‌کند. enable شرایط اجرای خودکار آن را برای Boot یا هدف تعیین‌شده فراهم می‌کند، اما لزوماً همان لحظه سرویس را Start نمی‌کند.

چگونه یک سرویس را هم‌زمان Start و Enable کنیم؟

از دستور زیر استفاده کنید:

sudo systemctl enable --now SERVICE

نام SERVICE را با Unit واقعی جایگزین کنید.

تفاوت Restart و Reload چیست؟

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

چگونه سرویس‌های Failed را مشاهده کنیم؟

دستور systemctl --failed یا systemctl list-units --type=service --state=failed را اجرا کنید.

daemon-reload چه زمانی لازم است؟

وقتی Unit File، Drop-in یا تنظیمات مربوط به systemd تغییر کرده باشد، از systemctl daemon-reload استفاده کنید. تغییر فایل تنظیمات خود برنامه الزاماً به این فرمان نیاز ندارد.

چگونه گزارش یک سرویس را مشاهده کنیم؟

از journalctl -u SERVICE استفاده کنید. برای گزارش Boot فعلی می‌توانید گزینه -b و برای دنبال‌کردن زنده گزینه -f را اضافه کنید.