عیب‌یابی خرابی سرویس‌ها بعد از Update در cPanel و DirectAdmin؛ بازیابی Apache، PHP، MySQL و Mail

اگر بعد از Update در cPanel یا DirectAdmin ناگهان سایت‌ها باز نمی‌شوند، PHP خطای 502 یا 503 می‌دهد، MariaDB بالا نمی‌آید، ایمیل قطع شده یا حتی خود پنل در دسترس نیست، اولین کار Reboot کردن سرور یا اجرای دوباره همه Updateها نیست. باید اول مشخص کنید دقیقاً کدام سرویس خراب شده، Update در چه مرحله‌ای تمام شده و اولین خطای واقعی داخل Log چیست.

در این راهنما یک مسیر عیب‌یابی کم‌خطر و مرحله‌ای داریم: ابتدا وضعیت Server و Update را ثبت می‌کنیم، بعد سرویس خراب را پیدا می‌کنیم، Log همان سرویس را می‌خوانیم و فقط در صورت وجود شواهد سراغ Repair، بازسازی Configuration یا نصب دوباره Package می‌رویم. مسیرهای cPanel/WHM و DirectAdmin جدا هستند تا دستورهای دو کنترل‌پنل با هم مخلوط نشوند.

این مقاله برای چه سروری نوشته شده است؟

این آموزش برای مدیر سروری است که به root SSH دسترسی دارد و cPanel/WHM یا DirectAdmin روی یک سیستم‌عامل لینوکسی پشتیبانی‌شده نصب شده است. اگر فقط User معمولی cPanel یا DirectAdmin هستید، بسیاری از دستورهای این مقاله برای شما قابل اجرا نیستند و باید متن خطا را برای مدیر Server یا Hosting Provider ارسال کنید.

در یک Incident واقعی، زمان مناسبی برای تعویض سیستم‌عامل یا مهاجرت کنترل‌پنل نیست. همان سیستم‌عامل فعلی را حفظ کنید و ابتدا سرویس‌ها را به وضعیت سالم برگردانید. دستورهای Service در این مقاله برای Serverهای مبتنی بر systemd نوشته شده‌اند؛ نام دقیق بعضی Unitها با توجه به Web Server، Database و تنظیمات Server ممکن است فرق کند.

قبل از هر Repair این پنج کار را انجام ندهید

مرحله ۱: قبل از تغییر، Snapshot یا Backup قابل بازگشت داشته باشید

اگر زیرساخت شما Snapshot سطح VPS یا Hypervisor دارد، قبل از Repairهای سنگین یک Snapshot بگیرید. اگر Snapshot در دسترس نیست، حداقل از Configurationهای سفارشی، Databaseهای مهم و فایل‌هایی که قرار است تغییر دهید Backup بگیرید.

در این مرحله هنوز چیزی را حذف یا Rebuild نمی‌کنیم؛ فقط یک نقطه بازگشت می‌سازیم. اگر Server میزبان چند سایت فعال است، Repairهای پرریسک را در بازه کم‌ترافیک انجام دهید.

مرحله ۲: مشخص کنید دقیقاً چه چیزی خراب شده است

عبارت «Server بعد از Update خراب شد» برای عیب‌یابی کافی نیست. باید نشانه را به یک سرویس یا لایه محدود کنید.

مرحله ۳: قبل از پنل، سلامت پایه Server را بررسی کنید

این دستورات روی خود Server و با دسترسی root اجرا می‌شوند. هنوز هیچ تغییری ایجاد نمی‌کنند؛ فقط وضعیت را می‌خوانند.

date
uptime
free -h
df -h
df -i
systemctl --failed --no-pager

این پنج بررسی ساده تعداد زیادی از خرابی‌های بعد از Update را جدا می‌کنند. اگر Disk یا Inode به 100% رسیده باشد، Package Manager و سرویس‌ها ممکن است نتوانند فایل جدید بسازند. اگر RAM تمام شده باشد، OOM Killer ممکن است Database یا PHP-FPM را متوقف کرده باشد.

برای خطاهای مهم Boot جاری:

journalctl -p err -b --no-pager | tail -n 200

اگر Server هنوز از زمان Update Reboot نشده، این خروجی می‌تواند Errorهای Service و Library را نشان دهد. وجود یک Error در Journal به‌تنهایی علت قطعی نیست؛ زمان آن را با زمان Update مقایسه کنید.

مرحله ۴: ببینید Port سرویس واقعاً Listen می‌کند یا نه

برای اینکه بفهمیم سرویس فقط در Panel «سبز» دیده می‌شود یا واقعاً Port دارد، از ss استفاده کنید:

ss -lntp | grep -E ':(80|443|2083|2087|2222|3306|25|465|587|993)\b'

چند Port مهم در این خروجی:

اگر Port مورد انتظار وجود ندارد، اول خود Service را بررسی کنید. اگر Port وجود دارد اما از بیرون قابل دسترس نیست، بعد سراغ Firewall، Network و NAT بروید.

مسیر اول: عیب‌یابی خرابی بعد از Update در cPanel/WHM

مرحله ۵: نسخه cPanel و تاریخ Update را ثبت کنید

روی Server cPanel با root اجرا کنید:

/usr/local/cpanel/cpanel -V
tail -5 /var/cpanel/updatelogs/summary.log
readlink -f /var/cpanel/updatelogs/last

دستور اول نسخه فعلی cPanel & WHM را نشان می‌دهد. دستور دوم تاریخ Updateهای اخیر را نمایش می‌دهد و دستور سوم مشخص می‌کند آخرین Update Log دقیقاً کدام فایل است.

مرحله ۶: اولین Error واقعی Update را پیدا کنید

grep " E " /var/cpanel/updatelogs/last | tail -n 80

cPanel در مستندات عیب‌یابی Update همین Directory را به‌عنوان محل اصلی بررسی Update Failure معرفی می‌کند. اگر grep چیزی نشان نداد یا Context کافی نبود، Log را با less بخوانید:

less /var/cpanel/updatelogs/last

برای پیام‌های مکمل خود cPanel:

tail -n 150 /usr/local/cpanel/logs/error_log

مرحله ۷: سرویس خراب را با ابزار خود cPanel بررسی کنید

cPanel برای Restart Serviceها اسکریپت restartsrv دارد. قبل از Restart، وضعیت سرویس مورد نظر را Check کنید. لازم نیست همه این دستورها را اجرا کنید؛ فقط سرویس مرتبط با نشانه را بررسی کنید.

/usr/local/cpanel/scripts/restartsrv_httpd --check
/usr/local/cpanel/scripts/restartsrv_mysql --check
/usr/local/cpanel/scripts/restartsrv_exim --check
/usr/local/cpanel/scripts/restartsrv_dovecot --check
/usr/local/cpanel/scripts/restartsrv_cpsrvd --check

اگر Apache مشکل دارد، ابتدا Configuration را بررسی کنید:

/usr/sbin/httpd -t

اگر نتیجه Syntax OK بود و Log مشکل دیگری نشان نمی‌دهد، Apache را با ابزار cPanel Restart کنید:

/usr/local/cpanel/scripts/restartsrv_httpd

اگر Syntax Error دارید، Restart مکرر چیزی را حل نمی‌کند. اول همان فایل، Module یا Include ذکرشده در Error را بررسی کنید.

مرحله ۸: اگر Packageهای cPanel ناقص یا خراب شده‌اند

cPanel ابزار رسمی برای بررسی Packageهای خودش دارد:

/usr/local/cpanel/scripts/check_cpanel_pkgs

این مرحله زمانی معنا دارد که Update Log یا Error سرویس به Package گم‌شده، خراب یا ناسازگار اشاره کند. آن را جایگزین بررسی Log نکنید.

مرحله ۹: چه زمانی Apache Config را Rebuild کنیم؟

اگر Error مشخصاً نشان می‌دهد Configuration تولیدشده Apache خراب یا ناقص است، cPanel فرمان رسمی زیر را برای بازسازی ارائه می‌کند:

/usr/local/cpanel/scripts/rebuildhttpdconf

فقط اگر Rebuild با موفقیت تمام شد، Apache را Restart کنید:

/usr/local/cpanel/scripts/restartsrv_httpd

مرحله ۱۰: upcp –force آخر کار است، نه اول کار

اگر Update Log نشان می‌دهد خود Update cPanel نیمه‌کاره مانده یا Packageهای اصلی به وضعیت ناسازگار رسیده‌اند، اجرای مجدد Update می‌تواند منطقی باشد. فرمان cPanel برای Update دستی:

/usr/local/cpanel/scripts/upcp --force

قبل از این کار Disk، Update Log و Backup را بررسی کنید. اگر مشکل فقط یک Apache Include یا یک PHP-FPM Unit است، Force Update کل پنل Repair هدفمندی نیست.

آیا بعد از خرابی Update می‌توان cPanel را Downgrade کرد؟

برای Major Version پاسخ عمومی خیر است. cPanel رسماً Downgrade از یک Major جدید به Major قبلی را پشتیبانی نمی‌کند. برای نمونه اگر از 136 به 138 ارتقا داده‌اید، نباید برنامه بازیابی را روی برگشت مستقیم به 136 بنا کنید.

cPanel برای بعضی Minor Buildهای همان Major مسیر Downgrade دارد، اما Pin کردن نسخه باعث می‌شود Updateهای امنیتی و Bug Fixهای جدید را دریافت نکنید. بنابراین Minor Downgrade فقط وقتی معنا دارد که Regression مشخص و مستند داشته باشید و Plan بازگشت به Release سالم را از قبل مشخص کرده باشید.

مسیر دوم: عیب‌یابی خرابی بعد از Update در DirectAdmin

مرحله ۱۱: نسخه DirectAdmin و Update Channel را ببینید

روی Server و با root اجرا کنید:

da version
da config-get update_channel

DirectAdmin برای Update خود پنل Channelهای جدا مانند current، stable و alpha دارد. اگر Server Production روی alpha قرار گرفته، این موضوع برای تحلیل خرابی مهم است؛ اما وسط Incident بدون بررسی Release Notes Channel را خودسرانه تغییر ندهید.

مرحله ۱۲: اول خود DirectAdmin را بررسی کنید

systemctl status directadmin --no-pager
journalctl -u directadmin.service -n 150 --no-pager
tail -n 100 /var/log/directadmin/error.log

اگر Port 2222 باز نیست و directadmin.service Failed شده، Error همین خروجی‌ها معمولاً از Restart مکرر اطلاعات بیشتری می‌دهد.

مرحله ۱۳: بفهمید Update خود DirectAdmin بوده یا CustomBuild

این تفاوت بسیار مهم است. در نسخه‌های جدید DirectAdmin، خود پنل با سیستم Update داخلی و فرمان da update مدیریت می‌شود. CustomBuild برای نرم‌افزارهای ثالث مثل Apache، Nginx، PHP، Exim و سایر Componentها استفاده می‌شود.

از DirectAdmin 1.704 به بعد، فرمان da build update_versions دیگر خود DirectAdmin را Update نمی‌کند. اگر بعد از اجرای CustomBuild سرویس خراب شده، اول Log همان CustomBuild را بررسی کنید.

فهرست نسخه‌های Componentهای مدیریت‌شده:

da build versions

CustomBuild Log اصلی:

tail -n 150 /usr/local/directadmin/custombuild/custombuild.log

برای دیدن Logهای Runهای اخیر CustomBuild:

ls -lt /var/log/directadmin/custombuild.*.log | head

فایل جدیدتر را با less یا tail باز کنید و اولین Error مربوط به Build را پیدا کنید.

مرحله ۱۴: سرویس واقعی نصب‌شده را پیدا کنید

DirectAdmin می‌تواند با Apache، Nginx، Nginx + Apache، LiteSpeed یا OpenLiteSpeed و چند نسخه PHP کار کند. پس نباید فرض کنیم نام Service روی همه Serverها یکی است.

systemctl list-units --type=service --all | grep -Ei 'directadmin|httpd|apache2|nginx|lsws|php-fpm|mariadb|mysql|exim|dovecot|named|pdns'

بعد فقط Unit مرتبط را بررسی کنید. برای مثال اگر Server واقعاً Nginx دارد:

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
nginx -t

اگر Apache نصب است، Syntax را بررسی کنید:

httpd -t

اگر توزیع شما Command را با نام apache2ctl ارائه می‌کند، از همان ابزار موجود روی Server استفاده کنید. مهم این است که قبل از Restart، Syntax Configuration بررسی شود.

مرحله ۱۵: اگر Configuration تولیدشده DirectAdmin خراب شده است

DirectAdmin برای بازنویسی Configurationهای مدیریت‌شده توسط CustomBuild فرمان زیر را دارد:

da build rewrite_confs

قبل از Rewrite، Customizationهای مهم را بررسی کنید:

find /usr/local/directadmin/custombuild/custom -maxdepth 3 -type f 2>/dev/null
find /usr/local/directadmin/data/templates/custom -maxdepth 2 -type f 2>/dev/null

اگر خروجی دارید، قبل از Rewrite از این مسیرها Backup بگیرید و مطمئن شوید Template قدیمی با Version جدید ناسازگار نشده است.

مرحله ۱۶: Rebuild فقط Component خراب، نه کل Stack

اگر Log مشخصاً نشان می‌دهد یک Component در CustomBuild ناقص Build شده، همان Component را Repair کنید. نمونه‌های رسمی CustomBuild شامل این فرمان‌ها هستند:

da build apache
da build php
da build nginx

همه این فرمان‌ها را پشت‌سرهم اجرا نکنید. فقط Componentی را Build کنید که واقعاً روی Server استفاده می‌شود و Log آن خرابی Build یا Library را نشان می‌دهد.

فرمان زیر همه Componentهای مدیریت‌شده را Reinstall/Build می‌کند:

da build all

DirectAdmin خودش تأکید می‌کند که این فرمان برای استفاده عادی توصیه نمی‌شود، چون تقریباً کل Software Stack تحت مدیریت CustomBuild را دوباره Build می‌کند. آن را آخرین گزینه Repair بدانید، نه مرحله دوم عیب‌یابی.

خطای 502 یا 503 بعد از Update؛ اول PHP-FPM را بررسی کنید

اگر Web Server بالا است اما سایت PHP خطای 502 Bad Gateway یا 503 Service Unavailable می‌دهد، احتمال دارد PHP-FPM Unit مربوط به نسخه PHP بالا نیامده باشد یا Socket تغییر کرده باشد.

اول Unitهای PHP-FPM موجود را پیدا کنید:

systemctl list-units --type=service --all | grep -i 'php.*fpm'

سپس Unit واقعی را جایگزین کنید. نمونه:

systemctl status php-fpm82.service --no-pager
journalctl -u php-fpm82.service -n 120 --no-pager

نام بالا فقط نمونه است و باید با Unit واقعی Server جایگزین شود. DirectAdmin در نسخه‌های جدید برای PHP-FPM Service Log استفاده از journalctl را مستند کرده است.

در cPanel ممکن است PHP-FPM تحت Packageهای EasyApache و Unitهای مخصوص همان نسخه PHP مدیریت شود. نام Unit را ابتدا از systemctl پیدا کنید و بعد همان را بررسی کنید.

Apache یا Nginx بعد از Update بالا نمی‌آید

اگر Error چیزی شبیه Cannot load module، undefined symbol یا Missing Library نشان می‌دهد، مشکل معمولاً با Restart بیشتر حل نمی‌شود. اول Syntax و Library Error را کامل بخوانید.

برای Apache:

/usr/sbin/httpd -t

برای Nginx:

nginx -t

اگر خطا Address already in use است، ببینید کدام Process Port را گرفته:

ss -lntp | grep -E ':(80|443)\b'

در Serverهای Nginx + Apache یا LiteSpeed، وجود چند Web Server لزوماً اشتباه نیست؛ مهم این است که معماری تنظیم‌شده کنترل‌پنل را بشناسید و Portها را با Templateهای آن هماهنگ نگه دارید.

MariaDB یا MySQL بعد از Update Start نمی‌شود

اول نام Service واقعی را پیدا کنید:

systemctl list-units --type=service --all | grep -Ei 'mariadb|mysql'

اگر MariaDB است:

systemctl status mariadb --no-pager
journalctl -u mariadb -n 150 --no-pager

اگر Log از InnoDB، Permission، Disk Full، Unsupported Option یا Upgrade System Tables صحبت می‌کند، همان خطا را حل کنید. حذف ibdata، پاک کردن Data Directory یا Initialize مجدد Database راه‌حل عیب‌یابی نیست و می‌تواند داده‌ها را از بین ببرد.

Exim و Dovecot بعد از Update خراب شده‌اند

برای Mail Server ابتدا Service Status را ببینید:

systemctl status exim --no-pager
systemctl status dovecot --no-pager

در cPanel مسیرهای مهم Exim شامل این Logها هستند:

tail -n 100 /var/log/exim_mainlog
tail -n 100 /var/log/exim_paniclog
tail -n 100 /var/log/maillog

در DirectAdmin، Exim معمولاً Logهای خود را زیر مسیر زیر دارد:

tail -n 100 /var/log/exim/mainlog
tail -n 100 /var/log/exim/paniclog
tail -n 100 /var/log/maillog

اگر paniclog پر شده است، قبل از Restart تکراری Exim متن خطا را بررسی کنید؛ معمولاً مشکل Configuration، Permission، Library یا Dependency قابل مشاهده است.

DNS بعد از Update خراب شده است

اول مشخص کنید DNS واقعاً روی همین Server Authoritative است یا دامنه از Cloudflare یا DNS Provider خارجی استفاده می‌کند. خراب بودن named روی Server وقتی Nameserver دامنه خارجی است ممکن است دلیل Down بودن سایت نباشد.

Serviceهای متداول DNS را پیدا کنید:

systemctl list-units --type=service --all | grep -Ei 'named|bind|pdns'

برای BIND:

named-checkconf

اگر این فرمان Syntax Error نشان داد، فایل و Line اعلام‌شده را اصلاح کنید و بعد Service را Restart کنید. اگر DNS خارجی دارید، Zone را در Provider واقعی دامنه بررسی کنید، نه صرفاً داخل کنترل‌پنل Server.

DirectAdmin بعد از Update باز نمی‌شود؛ Debug Mode چه زمانی مفید است؟

اگر journalctl و error.log علت را نشان نمی‌دهند، DirectAdmin Debug Mode دارد. این مرحله باعث توقف موقت Service Panel می‌شود، بنابراین باید فقط زمانی اجرا شود که SSH شما پایدار است و می‌دانید چطور Service را دوباره Start کنید.

ابتدا DirectAdmin را متوقف کنید:

systemctl stop directadmin

سپس Debug سطح 2000:

da server --debug=2000

بعد از مشاهده Error، با Ctrl+C Debug را متوقف کنید و Service عادی را برگردانید:

systemctl start directadmin

Downgrade در DirectAdmin؛ فقط وقتی Regression اثبات شده است

DirectAdmin امکان Update به Build مشخص با Commit Hash را مستند کرده است. این قابلیت برای Debug و Regression مفید است، اما به معنی این نیست که پس از هر خرابی باید نسخه قبلی را نصب کنید.

اگر واقعاً ثابت شده Build جدید Bug مشخصی دارد، قبل از نصب Build مشخص باید Snapshot داشته باشید، Release Notes را بخوانید و رفتار Auto-update/Autopatch را در نظر بگیرید. در غیر این صورت DirectAdmin می‌تواند طبق Update Channel دوباره به Version جدید برگردد.

برای Incidentهای معمول، Repair سرویس یا Config خراب از Rollback کل Panel کم‌ریسک‌تر است.

چطور بفهمیم Update واقعاً علت خرابی بوده است؟

هم‌زمانی به‌تنهایی اثبات علت نیست. ممکن است Update ساعت 03:00 تمام شده باشد ولی Disk ساعت 04:30 پر شده باشد یا Certificate در همان روز Expire شده باشد.

برای اثبات ارتباط، این سه زمان را کنار هم قرار دهید:

اگر اولین Error درست بعد از تغییر Package یا Config مشخص ظاهر شده، فرضیه Update قوی‌تر می‌شود. اگر Error ساعت‌ها قبل از Update وجود داشته، باید دنبال علت دیگری باشید.

چک‌لیست سریع براساس نوع خرابی

بعد از Repair چطور مطمئن شویم Server واقعاً سالم شده است؟

فقط سبز شدن systemctl کافی نیست. مسیر واقعی کاربر را آزمایش کنید.

systemctl --failed --no-pager

چطور جلوی تکرار خرابی بعد از Update را بگیریم؟

هیچ Updateای بدون ریسک نیست، اما می‌توان Blast Radius را کوچک کرد.

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

بعد از Update اولین کار Restart کردن Server است؟

خیر. اول Service Failed، Update Log و Error Log را بررسی کنید. Reboot می‌تواند Downtime را بیشتر کند و بدون حل Configuration یا Package خراب، مشکل بعد از Boot دوباره برمی‌گردد.

آیا upcp –force همه مشکلات cPanel را حل می‌کند؟

خیر. این فرمان کل Update cPanel را دوباره اجرا می‌کند و برای هر Error مناسب نیست. اگر مشکل از یک Apache Include، PHP-FPM Unit یا Database Configuration باشد، Repair هدفمند منطقی‌تر است.

در DirectAdmin بعد از Update باید da build all اجرا کنیم؟

به‌صورت پیش‌فرض خیر. مستندات DirectAdmin این فرمان را برای Build مجدد همه Componentها معرفی می‌کنند و برای استفاده عادی توصیه نمی‌کنند. ابتدا Component خراب را از Log مشخص کنید.

فرق da update و da build update_versions چیست؟

da update خود DirectAdmin را طبق Update Channel مدیریت می‌کند. da build update_versions مربوط به Softwareهای مدیریت‌شده با CustomBuild است و از DirectAdmin 1.704 به بعد دیگر خود DirectAdmin را Update نمی‌کند.

آیا می‌توان cPanel را به Major قبلی برگرداند؟

cPanel بازگشت از Major Version جدید به Major قبلی را پشتیبانی نمی‌کند. برای Minor Buildهای همان Major شرایط متفاوت است، اما Pin کردن نسخه می‌تواند دریافت Security Update را متوقف کند.

اگر بعد از Update فقط یک سایت خراب شده باشد چه؟

وقتی بقیه سایت‌ها سالم‌اند، احتمال خرابی Web Server سراسری کمتر است. PHP Version همان Domain، .htaccess، VirtualHost، Permission، Extensionهای PHP و Application Log همان سایت را بررسی کنید.

چطور بفهمیم مشکل از Update است یا هم‌زمان اتفاق افتاده؟

Timestamp Update Log را با اولین Error سرویس و زمان Monitoring Alert مقایسه کنید. اگر Error دقیقاً پس از تغییر Package یا Config ایجاد شده باشد، ارتباط قوی‌تر است؛ هم‌زمانی به‌تنهایی دلیل قطعی نیست.

جمع‌بندی

منابع رسمی

cPanel: پیدا کردن Error در Update Failure

cPanel: مستندات restartsrv

cPanel: Repair Packageهای خراب با check_cpanel_pkgs

DirectAdmin: عیب‌یابی سرویس DirectAdmin

DirectAdmin: عیب‌یابی CustomBuild

DirectAdmin: Update و Rebuild سرویس‌های CustomBuild