محتوای آموزشی وبلاگ نت‌آرام
برنامه قبل از خاموش و روشن شدن سرور کار می‌کرد اما بعد از بالا آمدن لینوکس اجرا نشده است. شاید سرویس برای شروع خودکار فعال نباشد، با خطای تنظیمات بسته شود یا در زمان شروع به یک وابستگی آماده‌نشده نیاز داشته باشد. ابتدا نام دقیق سرویس را پیدا کنید؛ example.service در دستورها فقط نمونه است.
نام و خطاهای روی تصویر نیز فرضی‌اند؛ نام سرویس خودتان را از دستورهای پایین به دست آورید.
ببینید سرویس فعال و سالم است یا نه
کد / دستورsystemctl is-enabled example.service
systemctl status example.service --no-pager
نتیجه enabled می‌گوید معمولاً سرویس برای شروع خودکار تنظیم شده است؛ به تنهایی ثابت نمی‌کند اکنون برنامه سالم است. Active و آخرین پیام‌ها در status وضعیت اجرای فعلی را نشان می‌دهند. اگر نام را نمی‌دانید، از مدیر برنامه یا فایل نصب آن بپرسید؛ نام حدسی را تغییر ندهید.
گزارش همین بوت را بخوانید
کد / دستورsudo journalctl -u example.service -b --no-pager -n 100
به اولین خطای مربوط به شروع سرویس توجه کنید. مسیر فایل پیکربندی اشتباه، نبود مجوز، پورت اشغال‌شده یا آماده نبودن پایگاه داده مثال‌های محتمل‌اند. گزارش ممکن است رمز، نشانی خصوصی یا داده مشتری داشته باشد؛ پیش از ارسال، بخش حساس را پاک کنید.
برای دیدن فرمان شروع و تنظیم وابستگی‌ها:
کد / دستورsystemctl cat example.service
systemctl show example.service -p User -p WorkingDirectory -p ExecStart -p After -p Requires
After فقط ترتیب را مشخص می‌کند و به تنهایی به معنی آماده بودن سرویس دیگر نیست. Requirements و روش بررسی آمادگی به برنامه بستگی دارد. فایل واحد را بدون شناخت کپی یا بازنویسی نکنید.
تغییر را در یک مورد مشخص آزمایش کنید
اگر سرویس مستقل است و مدیر آن تأیید می‌کند باید همراه سیستم شروع شود، می‌توانید پس از رفع خطا آن را فعال و اجرا کنید:
کد / دستورsudo systemctl enable --now example.service
این دستور وضعیت واقعی سرور را تغییر می‌دهد. برای برنامه حساس، قبل از اجرا اثر آن بر کاربران و توقف یا اجرای هم‌زمان نسخه دیگر را بسنجید. اگر پیام failed تکرار شد، به جای تلاش‌های پیاپی علت ثبت‌شده را بخوانید.
اگر خطا مسیر فایل را نشان می‌دهد
فرض کنید در گزارش نوشته شده فایل پیکربندی پیدا نشد. از خروجی
systemctl cat example.service مسیر مشخص‌شده در فرمان شروع را بردارید و با مسیر واقعی فایل همان برنامه مقایسه کنید. در صورت اشتباه، پیش از ویرایش از تنظیم فعلی نسخه بگیرید و فقط مسیر صحیح را در روش تنظیم پیشنهادی سازنده اصلاح کنید. اگر فایل واحد systemd تغییر کرده است، مدیر پس از کنترل ساختار sudo systemctl daemon-reload را اجرا می‌کند؛ سپس سرویس را طبق برنامه راه‌اندازی و گزارش همان بوت را دوباره می‌خواند. نام سرویس نمونه است.نتیجه را واقعی تأیید کنید
فقط سبز بودن status کافی نیست. آدرس یا عملکرد برنامه را امتحان کنید؛ برای مثال یک درخواست سالم یا اتصال داخلی کنترل‌شده بفرستید. اگر لازم است بعد از یک ری‌استارت برنامه آزمایش شود، زمان آن را هماهنگ کنید و پیش از آن دسترسی کنسول و روش بازگشت را داشته باشید. پس از راه‌اندازی دوباره، هم status و هم رفتار برنامه را بررسی کنید.
اگر سرویس فقط بعد از یک تأخیر دستی کار می‌کند، ساعت اولین خطا و زمان آماده شدن وابستگی را کنار هم بگذارید. افزودن تأخیر طولانی همیشه علت را رفع نمی‌کند؛ شاید فایل تنظیم اشتباه باشد یا برنامه به اتصال پایگاه داده نیاز داشته باشد. مسیر دقیق وابستگی را با مستندات همان برنامه و مدیر آن هماهنگ کنید.
منبع: مستندات رسمی.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام