محتوای آموزشی وبلاگ نت‌آرام
سرویسی روی سرور اجرا نمی‌شود و در خروجی وضعیت آن عبارت
start-limit-hit می‌بینید. ممکن است چند بار دکمه شروع را زده باشید یا سرویس خودش چند بار پشت سر هم تلاش کرده باشد. این پیام می‌گوید systemd برای جلوگیری از تلاش‌های پی‌درپی، موقتاً جلوی شروع دوباره آن واحد را گرفته است؛ اما علت اولیه خراب شدن برنامه را به‌تنهایی مشخص نمی‌کند.برای مثال ممکن است فایل تنظیمات برنامه اشتباه باشد، پورت لازم را برنامه دیگری گرفته باشد یا فایل موردنیاز در مسیر اشتباهی قرار داشته باشد. در این آموزش ابتدا خطای واقعی پیش از
start-limit-hit را پیدا می‌کنیم، بعد متناسب با همان خطا اقدام می‌کنیم و در پایان سرویس را دوباره می‌آزماییم.این مراحل را کجا اجرا کنیم؟
دستورها برای سرور لینوکسی دارای systemd هستند. به ترمینال سرور، مثلاً از طریق SSH، وصل شوید. کاربر شما برای بعضی دستورها به مجوز
sudo نیاز دارد. در نمونه‌های زیر example.service فقط نام فرضی است؛ آن را هر بار با نام واقعی سرویس خودتان جایگزین کنید.اگر سرویس روی هاست اشتراکی است و دسترسی مدیریتی ندارید، زمان خطا و نشانی صفحه آسیب‌دیده را نگه دارید و آن‌ها را به مدیر هاست بدهید. دستورهای مدیریتی را نمی‌توان از پیشخوان وردپرس اجرا کرد.
برای سرویس تولیدی، تغییر یا راه‌اندازی مجدد ممکن است درخواست‌های کاربران را قطع کند. پیش از دست‌کاری تنظیمات، نسخه‌ای از فایل مرتبط نگه دارید و اگر سرویس دسترسی مهمی مانند SSH را فراهم می‌کند، کنسول جایگزین سرور را آماده کنید. هدف ما شروع‌کردن پشت سر هم سرویس نیست؛ اول می‌خواهیم دلیل شکست را پیدا کنیم.
قدم اول: خطای قبل از توقف تلاش‌ها را پیدا کنید
وضعیت سرویس را ببینید:
کد / دستورsystemctl status example.service --no-pager -l
این فرمان وضعیت و چند خط اخیر را نشان می‌دهد. در خروجی، نام واقعی سرویس، عبارت
کد / دستورActive و بخش Result را بخوانید. اگر فقط start-limit-hit دیده می‌شود، برای یافتن علت، گزارش بیشتری لازم است:sudo journalctl -u example.service -n 150 --no-pager
این فرمان ۱۵۰ خط آخر گزارش همان واحد را نشان می‌دهد و چیزی را تغییر نمی‌دهد. از آخر به عقب بروید تا به نخستین شکستِ قبل از تلاش‌های پی‌درپی برسید. متن‌هایی مانند
address already in use، permission denied، no such file یا خطای پیکربندی، سرنخ‌های متفاوتی هستند. نام فایل، زمان و شماره خط را یادداشت کنید.اگر صدها پیام تکراری علت اصلی را پنهان کرده‌اند، می‌توانید به‌جای عدد
150 تعداد مناسب بیشتری بگذارید. اگر گزارش خالی است، شاید نام واحد اشتباه باشد یا برنامه گزارش خود را در جای دیگری بنویسد؛ راهنمای پیدا کردن گزارش سرویس در journalctl را ببینید. گزارش‌ها می‌توانند رمز یا مسیر خصوصی داشته باشند؛ پیش از اشتراک‌گذاری آن‌ها را پاک کنید.اگر خطا می‌گوید پورت قبلاً استفاده شده است
پیام
کد / دستورAddress already in use معمولاً یعنی برنامه نتوانسته آدرس و پورتی را که می‌خواهد باز کند. برای دیدن برنامه‌های در حال گوش‌دادن، این فرمان را اجرا کنید:sudo ss -ltnp
فهرست پورت‌های TCP در حال گوش‌دادن نمایش داده می‌شود. شماره پورتی را که در گزارش خطا آمده پیدا کنید و نام برنامه مسئول را بخوانید. خروجی همه پورت‌ها را نشان می‌دهد؛ وجود پورت باز به‌تنهایی خطا نیست.
اگر سرویس قدیمی یا نسخه دیگری از همان برنامه پورت را گرفته است، ابتدا مشخص کنید کدام سرویس باید فعال بماند. در صورت امکان، تنظیم پورت برنامه آزمایشی را عوض کنید یا با مدیر سرور درباره توقف نسخه اضافی هماهنگ شوید. بی‌دلیل همه برنامه‌های روی پورت را متوقف نکنید؛ ممکن است سایت یا پایگاه داده دیگری به آن‌ها وابسته باشد. جزئیات بیشتر در راهنمای پیدا کردن برنامه‌ای که پورت را گرفته آمده است.
اگر خطا به فایل، دسترسی یا تنظیمات اشاره دارد
برای
No such file or directory مسیر نوشته‌شده در گزارش را با فایل تنظیمات برنامه مقایسه کنید. شاید نام مسیر اشتباه باشد، فایل پس از انتقال در جای دیگری قرار گرفته یا فضای ذخیره‌سازی لازم هنوز وصل نشده باشد. مسیر را بر اساس راهنمای همان برنامه اصلاح کنید؛ یک فایل خالی و تصادفی با همان نام نسازید.اگر پیام
کد / دستورPermission denied می‌بینید، مشخص کنید سرویس با کدام کاربر اجرا می‌شود و آن کاربر برای خواندن فایل یا پیمودن پوشه‌ها چه دسترسی‌ای لازم دارد. این دستور خصوصیات ثبت‌شده واحد را نشان می‌دهد:systemctl show example.service -p User -p Group -p ExecStart
خروجی به شما در شناسایی حساب و فرمان سرویس کمک می‌کند. خالی بودن بعضی مقادیر لزوماً خطا نیست و ممکن است به حالت پیش‌فرض واحد مربوط باشد. به همه فایل‌ها دسترسی عمومی ندهید و
chmod 777 را به‌عنوان راه‌حل عمومی اجرا نکنید. دسترسی درست به نوع فایل، مالکیت، مسیر و سیاست امنیتی همان سیستم بستگی دارد.اگر برنامه برای فایل تنظیماتش دستور آزمون رسمی دارد، ابتدا از همان دستور استفاده کنید. برای نمونه، در سروری که Nginx واقعاً نصب و مسئول سرویس است، دستور زیر تنظیمات آن را آزمون می‌کند:
کد / دستورsudo nginx -t
اگر پیام موفقیت گرفتید، آزمون نحوی تنظیمات گذشته است؛ این نتیجه به‌تنهایی ثابت نمی‌کند همه درخواست‌های سایت درست پاسخ می‌گیرند. اگر خطا شماره خط و نام فایل داد، همان خط را با مستندات برنامه تطبیق دهید و پس از اصلاح دوباره آزمون کنید. برای Apache یا برنامه دیگر از دستور آزمون مخصوص همان نرم‌افزار استفاده کنید، نه دستور Nginx.
پس از رفع علت، شمارنده شکست را پاک و سرویس را شروع کنید
وقتی دلیل اولیه را مشخص و اصلاح کرده‌اید و زمان شروع سرویس مناسب است، نام واقعی واحد را جایگزین کنید:
کد / دستورsudo systemctl reset-failed example.service
sudo systemctl start example.service
فرمان اول وضعیت شکست و شمارنده مربوط را پاک می‌کند؛ فایل خراب، پورت اشغال‌شده یا مشکل دسترسی را تعمیر نمی‌کند. فرمان دوم یک تلاش تازه برای شروع سرویس انجام می‌دهد. اگر علت باقی مانده باشد، خطا دوباره رخ می‌دهد و پس از تکرار ممکن است دوباره به محدودیت شروع برسید. طبق راهنمای systemd،
start-limit-hit نتیجه رسیدن به سقف تلاش‌های شروع است.پس از اجرا، وضعیت و آخرین گزارش را ببینید:
کد / دستورsystemctl status example.service --no-pager -l
sudo journalctl -u example.service -n 30 --no-pager
اگر سرویس دوباره شکست خورد، نخستین پیام جدید را با پیام قبلی مقایسه کنید. ممکن است پس از رفع یک اشکال، وابستگی دیگری آشکار شده باشد. اگر وضعیت فعال است، یک درخواست واقعیِ مرتبط با برنامه نیز بفرستید؛ صرف
active بودن همیشه به معنی سالم بودن سایت یا اتصال پایگاه داده نیست.اگر مشکل دوباره بعد از چند دقیقه برمی‌گردد
زمان و تعداد تلاش‌ها را در گزارش ببینید و بررسی کنید آیا برنامه پس از شروع، هنگام یک کار خاص از کار می‌افتد. پُر بودن دیسک، از دسترس خارج شدن سرویس وابسته یا خطای خود برنامه می‌توانند نشانه‌های متفاوتی ایجاد کنند. برای هرکدام باید شواهد همان مشکل را پیدا کرد؛ تغییر یک عدد در تنظیمات systemd بدون شناخت علت کافی نیست.
مقادیر
Restart و محدودیت تعداد تلاش‌ها ممکن است در واحد یا فایل‌های تکمیلی تنظیم شده باشند. بالا بردن نامحدود تعداد تلاش‌ها راه تعمیر برنامه نیست و می‌تواند بار بیشتری به سرور بدهد. اگر نیاز به تغییر رفتار شروع مجدد دارید، مستندات نسخه systemd و برنامه خود را ببینید، تغییر را اول در محیط آزمایشی بسنجید و مقدار قبلی را برای بازگشت نگه دارید.برای آشنایی با منابع و کنترل مدیریتی، صفحه سرور مجازی ایران نت‌آرام را ببینید. خطای پیکربندی یا اشغال پورت با افزایش منابع به‌تنهایی حل نمی‌شود.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام