آموزش شناسایی و رفع خطای سرویسهای Failed در لینوکس
یکی از خطاهای رایج در مدیریت سرورهای لینوکس، متوقفشدن یا اجرا نشدن سرویسها است. زمانی که یک سرویس بهدرستی اجرا نشود، systemd ممکن است وضعیت آن را به صورت failed نمایش دهد. این مشکل میتواند به دلایلی مانند تنظیمات اشتباه، اشغال بودن پورت، کمبود منابع، خطای دسترسی، خراب شدن فایلهای سرویس یا مشکل در وابستگیهای آن ایجاد شود.
برای رفع این خطا، فقط اجرای مجدد سرویس کافی نیست. ابتدا باید علت اصلی خطا شناسایی شود. لینوکس ابزارهای قدرتمندی مانند systemctl و journalctl در اختیار مدیر سرور قرار میدهد که با استفاده از آنها میتوان وضعیت سرویس، لاگهای مرتبط و دلیل توقف آن را بررسی کرد.
در این مطلب، روش شناسایی سرویسهای Failed، مشاهده جزئیات خطا، بررسی لاگها و رفع مشکلات رایج سرویسها را مرحلهبهمرحله بررسی میکنیم.
سرویس Failed در لینوکس به چه معناست؟
در بسیاری از توزیعهای جدید لینوکس مانند Ubuntu، Debian، AlmaLinux و Rocky Linux، مدیریت سرویسها بر عهده systemd است. این سیستم وظایفی مانند اجرای سرویسها هنگام بوت، کنترل وضعیت آنها و ثبت لاگهای مربوط به اجرای سرویس را انجام میدهد.
هر سرویس معمولا یکی از وضعیتهای مختلف مانند active، inactive یا failed را دارد.
وقتی وضعیت یک سرویس failed باشد، یعنی systemd تلاش کرده سرویس را اجرا کند یا سرویس در حال اجرا بوده، اما به دلیل یک خطا متوقف شده است.
برای مشاهده وضعیت یک سرویس میتوان از دستور زیر استفاده کرد:
در این دستور، nginx نام سرویس موردنظر است و میتوان آن را با سرویسهایی مانند apache2، mysql، ssh یا هر سرویس دیگری جایگزین کرد.
خروجی این دستور معمولا اطلاعات مهمی مانند وضعیت سرویس، زمان آخرین اجرا، PID، فرمان اجرا شده و چند خط آخر لاگ را نمایش میدهد.
چگونه سرویسهای Failed را در لینوکس پیدا کنیم؟
اگر نمیدانید کدام سرویس روی سرور با مشکل مواجه شده است، نیازی نیست وضعیت تکتک سرویسها را بررسی کنید.
systemd امکان نمایش تمام سرویسهایی را که در وضعیت Failed قرار دارند فراهم میکند:
برای مشاهده اطلاعات بیشتر میتوانید از این دستور استفاده کنید:
این دستور به ویژه هنگام عیبیابی سرورهایی که سرویسهای زیادی روی آنها فعال هستند بسیار کاربردی است.
بررسی دقیق وضعیت یک سرویس با systemctl
پس از پیدا کردن سرویس مشکلدار، اولین مرحله بررسی وضعیت آن است.
برای مثال:
اگر سرویس Failed شده باشد، معمولا در خروجی اطلاعاتی مانند Active: failed نمایش داده میشود.
همچنین چند خط آخر لاگ سرویس در همین خروجی قابل مشاهده است. این بخش گاهی مستقیم علت مشکل را مشخص میکند.
برای مشاهده وضعیت بدون اطلاعات اضافی میتوان از این دستور استفاده کرد:
یا برای بررسی اینکه سرویس در حالت Failed قرار دارد:
با این حال، برای عیبیابی واقعی معمولا باید سراغ لاگها برویم.
مشاهده لاگ سرویس با journalctl
یکی از مهمترین ابزارها برای بررسی خطاهای systemd، دستور journalctl است.
برای مشاهده لاگهای مربوط به یک سرویس میتوان از دستور زیر استفاده کرد:
اگر حجم لاگ زیاد باشد، بهتر است فقط آخرین خطوط را مشاهده کنید:
برای مشاهده لاگها از انتهای خروجی و دنبال کردن لاگهای جدید نیز میتوان از گزینه -f استفاده کرد:
این حالت مشابه tail -f عمل میکند و برای مشاهده خطا هنگام Restart کردن سرویس بسیار کاربردی است.
برای مشاهده خطاهای سرویس در بوت جاری نیز میتوانید از این دستور استفاده کنید:
در صورتی که مشکل مربوط به یک بوت قبلی باشد، بررسی بوتهای قبلی نیز میتواند مفید باشد:
چرا Restart کردن سرویس همیشه مشکل را حل نمیکند؟
یکی از اشتباهات رایج هنگام مشاهده وضعیت Failed این است که مدیر سرور بلافاصله سرویس را Restart میکند:
اگر مشکل موقتی باشد، Restart میتواند سرویس را دوباره فعال کند. اما اگر علت اصلی همچنان وجود داشته باشد، سرویس دوباره Failed خواهد شد.
برای همین بهتر است ابتدا لاگ را بررسی کنید، علت خطا را پیدا کنید و سپس سرویس را Restart کنید.
پس از اعمال تغییرات میتوانید وضعیت سرویس را دوباره بررسی کنید:
خطای اشغال بودن پورت
یکی از دلایل رایج Failed شدن سرویسها، استفاده شدن پورت موردنیاز توسط یک پردازش دیگر است.
برای بررسی پورتهای در حال استفاده میتوانید از ss استفاده کنید:
برای بررسی یک پورت خاص، مثلا پورت 80:
اگر سرویس دیگری از پورت موردنیاز استفاده کند، باید مشخص شود کدام پردازش پورت را اشغال کرده است.
برای مثال، ممکن است یک سرویس قدیمی هنوز در حال اجرا باشد یا تنظیمات دو سرویس به گونهای باشد که هر دو بخواهند روی یک پورت Listen کنند.
در چنین شرایطی ابتدا باید سرویس یا پردازش متداخل را شناسایی کرد و سپس تنظیمات مربوط به پورت را اصلاح کرد.
بررسی خطاهای فایل تنظیمات
گاهی سرویس به دلیل اشتباه در فایل Configuration اجرا نمیشود.
این اتفاق در سرویسهایی مانند Nginx، Apache، PHP-FPM، SSH و سرویسهای دیتابیس بسیار رایج است.
برای مثال، Nginx قبل از Restart شدن میتواند تنظیمات خود را بررسی کند:
اگر Configuration دارای خطا باشد، معمولا محل خطا در خروجی مشخص میشود.
در این شرایط به جای ریستارت مکرر، ابتدا باید فایل تنظیمات اصلاح و سپس سرویس اجرا شود.
برای سرویسهای دیگر هم باید از ابزار بررسی Configuration مخصوص همان سرویس استفاده کرد.
بررسی Permission و مالکیت فایلها
مشکل دسترسی، یکی دیگر از دلایل Failed شدن سرویسها است.
یک سرویس ممکن است برای اجرا نیاز داشته باشد فایل خاصی را بخواند، در یک مسیر بنویسد یا به یک Socket دسترسی داشته باشد.
برای بررسی مالکیت و Permission یک فایل میتوانید از دستور زیر استفاده کنید:
اگر سرویس با کاربر خاصی اجرا میشود، باید اطمینان حاصل کنید که همان کاربر به فایلها و مسیرهای موردنیاز دسترسی دارد.
برای مشاهده کاربری که سرویس با آن اجرا میشود نیز میتوانید Configuration سرویس را بررسی کنید:
این دستور فایل Unit سرویس و تنظیمات مربوط به اجرای آن را نمایش میدهد.
بررسی وابستگیهای سرویس
بعضی سرویسها برای اجرا به سرویسهای دیگری وابسته هستند. اگر سرویس وابسته اجرا نشده باشد، ممکن است سرویس اصلی نیز با مشکل مواجه شود.
برای مشاهده وابستگیهای یک سرویس میتوان از دستور زیر استفاده کرد:
همچنین میتوان بررسی کرد که یک سرویس چه Unitهایی را نیاز دارد.
این موضوع در سرویسهای پیچیدهتر اهمیت زیادی دارد، زیرا ممکن است خطای مشاهدهشده مربوط به خود سرویس اصلی نباشد و مشکل در یکی از Dependencyهای آن وجود داشته باشد.
بررسی سرویسهایی که بعد از ریبوت اجرا نمیشوند
گاهی سرویس در حالت عادی بهدرستی اجرا میشود اما پس از ریستارت یا ریبوت سرور بالا نمیآید.
در چنین شرایطی باید وضعیت Enable بودن سرویس بررسی شود:
اگر سرویس باید هنگام Boot به صورت خودکار اجرا شود، میتوان آن را Enable کرد:
در صورت نیاز میتوان Enable و Start را همزمان انجام داد:
البته Enable کردن سرویس فقط باعث اجرای خودکار آن در Boot میشود و خطاهای Configuration یا Runtime را برطرف نمیکند.
بررسی خطاهای مربوط به منابع سیستم
گاهی سرویس به دلیل کمبود منابع سیستم متوقف میشود. کمبود RAM، فضای دیسک یا محدودیتهای مربوط به پردازشها میتواند باعث بروز چنین مشکلاتی شود.
برای بررسی RAM میتوانید از دستور زیر استفاده کنید:
برای بررسی فضای دیسک:
همچنین برای مشاهده پردازشها و مصرف منابع میتوان از ابزارهایی مانند top یا htop استفاده کرد.
اگر فضای پارتیشن مربوط به /var یا / کاملا پر شده باشد، بسیاری از سرویسها ممکن است نتوانند فایلهای موردنیاز خود را ایجاد یا تغییر دهند.
بنابراین هنگام بررسی سرویسهای Failed، وضعیت منابع سیستم را هم باید در نظر گرفت.
بررسی خطاهای Boot و System-wide
گاهی مشکل فقط به یک سرویس محدود نیست و چند سرویس مختلف پس از Boot با خطا مواجه شدهاند.
برای مشاهده خطاهای جدی ثبتشده توسط Kernel و systemd میتوانید از این دستور استفاده کنید:
این دستور خطاهای سطح err مربوط به Boot جاری را نمایش میدهد.
برای مشاهده پیامهای مهمتر در سطح Warning و بالاتر هم میتوان از دستور زیر استفاده کرد.
این روش برای زمانی مفید است که هنوز مشخص نیست کدام بخش سیستم باعث ایجاد مشکل شده است.
پاک کردن وضعیت Failed بعد از رفع مشکل
پس از اینکه مشکل سرویس برطرف شد، معمولا systemd در اجرای بعدی وضعیت صحیح را نمایش میدهد.
در بعضی شرایط ممکن است بخواهید وضعیت Failed ثبتشده را پاک کنید:
برای پاک کردن وضعیت Failed همه Unitها، میتوان از دستور زیر استفاده کرد.
توجه داشته باشید که reset-failed علت مشکل را برطرف نمیکند. این دستور فقط وضعیت Failed ثبتشده توسط systemd را Reset میکند.
بنابراین اگر مشکل اصلی همچنان وجود داشته باشد، سرویس دوباره Failed خواهد شد.
یک روند استاندارد برای عیبیابی سرویس Failed
برای اینکه عیبیابی سرویسها سریعتر و اصولیتر انجام شود، بهتر است همیشه یک روند مشخص را دنبال کنید.
ابتدا لیست سرویسهای Failed را مشاهده کنید:
سپس وضعیت سرویس موردنظر را بررسی کنید:
در مرحله بعد، لاگ سرویس را مشاهده کنید:
اگر علت خطا مشخص نبود، لاگهای Boot و خطاهای سیستم را بررسی کنید:
پس از آن مواردی مانند Configuration، پورت، Permission، Dependency، فضای دیسک و منابع سیستم را بررسی کنید.
در نهایت، بعد از اصلاح مشکل، سرویس را ریستارت کنید:
و وضعیت نهایی را بررسی نمائید:
این روش باعث میشود به جای آزمون و خطای مکرر، علت واقعی مشکل را پیدا کنید.
نکات مهم هنگام رفع خطای سرویسها
هنگام عیبیابی سرویسهای Failed بهتر است از تغییرات تصادفی در Configuration خودداری کنید. هر تغییر باید بر اساس خطایی باشد که در Status یا Log مشاهده شده است.
همچنین قبل از ویرایش فایلهای حساس، بهتر است از فایل Configuration بکاپ تهیه کنید. این موضوع به ویژه روی سرورهای پروداکشن اهمیت زیادی دارد.
اگر یک سرویس پس از تغییر تنظیمات Failed شده است، ابتدا آخرین تغییرات انجامشده را بررسی کنید. در بسیاری از موارد، مشکل مستقیم به همان تغییر مربوط است.
همچنین نباید فقط با اجرای systemctl restart به صورت مکرر تلاش کرد مشکل را حل کرد. اگر سرویس به دلیل Configuration اشتباه، پورت اشغال، Permission یا Dependency نامناسب متوقف شده باشد، ریستارت مکرر فقط زمان عیبیابی را افزایش میدهد.
جمعبندی
خطای failed در systemd به خودی خود علت مشکل را مشخص نمیکند، بلکه نشان میدهد اجرای سرویس با مشکل مواجه شده است. برای پیدا کردن علت واقعی باید وضعیت سرویس و لاگهای آن بررسی شود.
مهمترین ابزارهای موردنیاز برای این کار systemctl و journalctl هستند. با systemctl –failed میتوان سرویسهای Failed را پیدا کرد، با systemctl status وضعیت یک سرویس را بررسی کرد و با journalctl -u جزئیات خطاهای مربوط به آن را مشاهده کرد.
در مرحله بعد هم باید مواردی مانند پورتهای در حال استفاده، فایلهای Configuration، Permission، Dependencyها، فضای دیسک و منابع سیستم بررسی شوند.
با استفاده از این روند، بیشتر خطاهای رایج سرویسهای لینوکس را میتوان بدون Restartهای مکرر و تغییرات غیرضروری شناسایی و برطرف کرد.