محتوای آموزشی وبلاگ نت‌آرام
پس از روشن‌شدن سرور، برنامه‌ای که باید به پایگاه داده راه دور وصل شود خطا می‌دهد؛ اما چند دقیقه بعد با راه‌اندازی دستی درست کار می‌کند. یکی از علت‌های ممکن این است که برنامه پیش از آماده‌شدن شبکه اجرا شده باشد. همین نشانه می‌تواند از آماده‌نبودن خود پایگاه داده، DNS اشتباه یا رمز نادرست هم ایجاد شود؛ قبل از تغییر ترتیب سرویس، شواهد را کنار هم می‌گذاریم.
این راهنما برای سرور لینوکسی دارای systemd و مدیر دارای دسترسی مناسب است. فرمان‌ها را ابتدا در محیط آزمایشی یا زمان نگهداری اجرا کنید؛ ریبوت سرور فعال را بدون برنامه و هماهنگی انجام ندهید.
۱. زمان خطا را از لاگ بخوانید
نام
کد / دستورmyapp.service را در همه دستورها با نام واقعی سرویس خودتان عوض کنید:systemctl status myapp.service --no-pager
journalctl -b -u myapp.service --no-pager
systemctl cat myapp.service
دستور اول وضعیت فعلی و دومی پیام‌های سرویس از آخرین بوت را نشان می‌دهد. سومی فایل سرویس و drop-inهای موجود را نمایش می‌دهد. زمان نخستین خطا را یادداشت کنید و ببینید پیام واقعاً درباره نبود شبکه، DNS، رد اتصال یا خطای ورود است. رمز و اطلاعات مشتری را هنگام اشتراک‌گذاری لاگ حذف کنید.
اگر خطا مثلاً
authentication failed است، صرف تأخیر شبکه رمز اشتباه را درست نمی‌کند. اگر پیام connection refused است، مسیر ممکن است برقرار باشد اما مقصد هنوز روی درگاه گوش ندهد. زمان آمادگی سرویس مقصد و دسترس‌پذیری آن را نیز بررسی کنید.۲. فرق دو هدف شبکه را بدانید
network.target یعنی بخش مدیریت شبکه شروع شده است؛ تضمین نمی‌کند رابط، آدرس، DNS یا اینترنت هنگام شروع برنامه آماده باشند. network-online.target منتظر شرایطی می‌ماند که سرویس مدیریت شبکه تعریف می‌کند. معنی دقیق «آماده» به مدیر شبکه و تنظیم آن بستگی دارد و به معنی آماده‌بودن پایگاه داده یا سالم‌ماندن دائمی اتصال نیست.فرمان‌های زیر را ببینید:
کد / دستورsystemctl is-active NetworkManager systemd-networkd
systemctl is-enabled NetworkManager-wait-online.service systemd-networkd-wait-online.service
systemctl list-dependencies network-online.target
ممکن است فقط یکی از دو مدیر شبکه استفاده شود و دیگری نصب نباشد؛ ناموجودبودن آن دیگری الزاماً خطا نیست. سرویس انتظار باید با مدیر واقعی شبکه و تنظیمات آن سازگار باشد. فعال‌سازی هم‌زمان یا تغییر مدیر شبکه بدون شناخت، اتصال سرور را به خطر می‌اندازد. اگر درباره شیوه اتصال سرور مطمئن نیستید، ابتدا با مدیر شبکه هماهنگ کنید.
۳. تنها برای سرویسی که واقعاً نیاز دارد وابستگی بگذارید
برای برنامه‌ای که هنگام شروع واقعاً به شبکه پیکربندی‌شده نیاز دارد، با دسترسی مدیر drop-in بسازید:
کد / دستورsudo systemctl edit myapp.service
پیش از ویرایش، خروجی
کد / دستورsystemctl cat و محتوای drop-in موجود را در نسخه پشتیبان نگه دارید؛ ممکن است همین فایل از قبل تنظیمات مهمی داشته باشد. در ویرایشگر، میان خطوط ویرایش‌پذیر این محتوا را بدون حذف تنظیمات قبلی قرار دهید و ذخیره کنید:[Unit]
Wants=network-online.target
After=network-online.target
Wants هدف را وارد برنامه شروع می‌کند و After ترتیب را مشخص می‌کند. این دو جایگزین هم نیستند. فرمان edit معمولاً پس از ذخیره، تنظیمات systemd را دوباره می‌خواند. با systemctl cat myapp.service وجود drop-in و با systemd-analyze critical-chain myapp.service ترتیب بوت ثبت‌شده را بررسی کنید.این تغییر ممکن است شروع سرویس یا بوت را تا آماده‌شدن شبکه یا پایان مهلت انتظار عقب بیندازد. آن را بی‌دلیل به همه سرویس‌ها اضافه نکنید. فعال‌بودن یک target نیز به تنهایی ثابت نمی‌کند مقصد بیرونی پاسخ می‌دهد.
۴. برای قطع‌شدن بعدی اتصال برنامه را مقاوم کنید
بهترین رفتار این است که برنامه برای اتصال ناموفق، خطای قابل فهم ثبت کند و با فاصله افزایشی و سقف منطقی دوباره تلاش کند. retry بی‌وقفه با فاصله صفر می‌تواند بار ایجاد کند. زمان انتظار و تعداد تلاش را با حساسیت برنامه تنظیم کنید؛ برای عملیات نوشتنی، تکرار باید با جلوگیری از ثبت دوباره داده همراه باشد.
اگر سرویس مقصد دیرتر از شبکه آماده می‌شود، لاگ هر دو سمت و DNS را بررسی کنید. در صورت نیاز، برنامه قبل از عملیات اصلی آمادگی واقعی مقصد را با محدودیت زمان بسنجد. منتظرماندن بی‌انتها برای یک نشانی خارجی می‌تواند سرویس را در حالت انتظار نگه دارد.
۵. آزمایش و بازگشت
در زمان نگهداری و محیطی که راه دسترسی جایگزین دارید، بوت آزمایشی انجام دهید؛ پس از آن وضعیت سرویس، زمان خطا و زنجیره راه‌اندازی را دوباره مقایسه کنید. فقط با دیدن
active بودن سرویس نتیجه نگیرید؛ یک عملیات واقعی و کم‌خطر برنامه که نیاز به مقصد دارد نیز انجام دهید.برای بازگرداندن تغییر، محتوای drop-in را از نسخه پشتیبان همان فایل برگردانید و وضعیت آن را با
systemctl cat myapp.service بررسی کنید. خالی‌کردن ویرایشگر ممکن است عملیات ویرایش را لغو کند و فایل قبلی را حذف نکند. اگر این نخستین drop-in بوده است، مدیر پس از شناسایی دقیق همان فایل تازه و اطمینان از نبود تنظیمات دیگر، آن را کنار بگذارد و sudo systemctl daemon-reload اجرا کند؛ از systemctl revert بدون بررسی استفاده نکنید، چون می‌تواند تغییرات محلی دیگری را نیز بازگرداند. راهنمای ویرایش امن drop-in جزئیات بیشتری دارد. برای دریافت کمک حرفه‌ای، مدیریت سرور نت‌آرام و برای تفاوت targetها، راهنمای systemd را ببینید.برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام