وردپرس
دسته بندی:
خطای Invalid command ‘MaxRequestWorkers’
خطای Invalid command 'MaxRequestWorkers' یعنی آپاچی اصلاً این دستور را نمیشناسد؛ چون MaxRequestWorkers متعلق به ماژول MPM است، نه هستهٔ آپاچی. پس یا هیچ ماژول MPM لود نشده، یا نسخهٔ آپاچی ۲.۲ است که در آن نام این دستور MaxClients بود، یا دستور در فایلی قرار گرفته که پیش از خط LoadModule مربوط به MPM خوانده میشود.
پیام خطا دقیقاً چه میگوید
متن کامل خطا معمولاً به این شکل است:
Invalid command 'MaxRequestWorkers', perhaps misspelled or defined by a module not included in the server configurationعبارت پایانی مهمترین بخش پیام است: «دستوری که ماژول ارائهدهندهاش در پیکربندی سرور نیست». این خطا با پیام مشابه MaxRequestWorkers not allowed here فرق دارد؛ آن یکی یعنی آپاچی دستور را میشناسد ولی جایش اشتباه است. این دستور فقط در سطح server config معتبر است و داخل <VirtualHost>، <Directory> یا .htaccess پذیرفته نمیشود. یعنی برای رفع آن به دسترسی روت و ویرایش کانفیگ اصلی نیاز دارید؛ کاری که روی VPS یا سرور فیزیکی ممکن است و روی هاست اشتراکی نه.
سه علتی که این خطا را میسازند
۱. هیچ ماژول MPM لود نشده است
در آپاچی ۲.۴ خودِ MPM یک ماژول قابل بارگذاری است: mod_mpm_prefork.so، mod_mpm_worker.so یا mod_mpm_event.so. تفاوت این سه و اینکه کدامیک برای بار کاری سرور شما مناسب است را در مفهوم MPM در Apache و انتخاب آن توضیح دادهایم. در بیشتر توزیعها این ماژولها به صورت DSO ساخته میشوند و دقیقاً یکی از آنها باید فعال باشد. اگر هر سه خط LoadModule کامنت شده باشند، تمام دستورهای وابسته به MPM شامل MaxRequestWorkers، ServerLimit، StartServers و ThreadsPerChild ناشناخته میشوند.
۲. نسخهٔ آپاچی ۲.۲ است
نام MaxRequestWorkers از آپاچی ۲.۴ معرفی شد و در ۲.۲ همین مفهوم با MaxClients بیان میشد. اگر روی سروری با آپاچی ۲.۲ یک کانفیگ آمادهٔ اینترنت را کپی کرده باشید، دقیقاً همین خطا را میگیرید. عکس این حالت مشکلی ندارد: آپاچی ۲.۴ نام قدیمی MaxClients را هنوز به عنوان معادل میپذیرد و فقط هشدار میدهد.
۳. ترتیب خوانده شدن فایلها
آپاچی کانفیگ را خطبهخط و به ترتیب میخواند. اگر MaxRequestWorkers در فایلی باشد که با Include پیش از خط LoadModule مربوط به MPM خوانده میشود، در لحظهٔ پردازش آن خط هنوز ماژول لود نشده و همان خطا صادر میشود. این حالت روی سرورهایی شایع است که کانفیگ دستی دارند و آن را بین چند فایل جداگانه تقسیم کردهاند.
گام اول: نسخه و MPM فعال را ببینید
پیش از هر تغییری وضعیت فعلی را مشخص کنید. روی CentOS، RHEL، AlmaLinux و Rocky:
httpd -V— خطServer versionنسخه و خطServer MPMنام MPM فعال را نشان میدهد.httpd -M | grep mpm— نشان میدهد کدام ماژول MPM لود شده وsharedاست یاstatic.
روی دبیان و اوبونتو همین دستورها با نام apache2ctl اجرا میشوند. اگر خروجی دستور دوم خالی بود، علت خطا همان مورد اول است.
فعال یا عوض کردن MPM
این کار به دسترسی روت و ریاستارت وبسرور نیاز دارد، پس روی سروری که در حال سرویسدهی است باید با احتیاط انجام شود؛ اگر ترجیح میدهید تیم فنی انجامش دهد، نصب، بهینهسازی و امنسازی وبسرور آپاچی هم بخشی از خدمات پشتیبانی و مدیریت سرور است.
روی خانوادهٔ RHEL، خطهای LoadModule مربوط به MPM در فایل /etc/httpd/conf.modules.d/00-mpm.conf هستند و فقط یکی از آنها باید بدون کامنت باشد؛ اگر دو تا را همزمان فعال کنید سرویس بالا نمیآید. روی دبیان و اوبونتو این کار با ابزار خود سیستم انجام میشود؛ مثلاً برای رفتن از prefork به event: a2dismod mpm_prefork و سپس a2enmod mpm_event.
اگر کنترلپنل دارید
در دایرکتادمین، کانفیگ آپاچی را CustomBuild از روی تمپلیتها میسازد؛ اگر پس از همین بازسازی بهجای سایت، صفحهٔ پیشفرض بالا آمد، رفع خطای Apache is functioning normally در دایرکتادمین همان حالت را بررسی کرده است. اگر خطا هنگام کامپایل مجدد آپاچی ظاهر شد، معمولاً تمپلیتها با نسخهٔ نصبشده همخوان نیستند و بازسازی کانفیگ مشکل را حل میکند:
cd /usr/local/directadmin/custombuild./build rewrite_confs
توجه کنید که این دستور فایلهای ساختهشده را بازنویسی میکند؛ هر تغییر دستی روی آنها از بین میرود، پس تنظیمهای سفارشی را در فایلهای custom بگذارید. در نسخههای جدیدتر، همین کار از طریق ابزار da build هم در دسترس است و اگر لایسنس دایرکتادمین منقضی شده باشد، CustomBuild نمیتواند بستهها را بهروزرسانی کند. در cPanel و EasyApache 4 هم تغییر را از بخش Apache Configuration در WHM اعمال کنید تا با ساخت دوبارهٔ کانفیگ پاک نشود.
هشدار: mod_php فقط با prefork کار میکند
پیش از تعویض MPM بررسی کنید PHP چطور اجرا میشود. ماژول mod_php از نظر thread-safe بودن امن نیست و فقط با prefork پشتیبانی میشود. اگر روی سروری که mod_php دارد MPM را به event یا worker ببرید، وبسرور یا بالا نمیآید یا رفتار ناپایدار پیدا میکند. و اگر در همین بازبینی به این نتیجه رسیدید که آپاچی برای بار کاری شما مناسب نیست، مقایسه وبسرورهای Apache، LiteSpeed، Nginx و IIS گزینههای دیگر را کنار هم گذاشته است. مسیر درست این است که اول PHP را به PHP-FPM منتقل کنید و بعد MPM را عوض کنید، آن هم در بازهٔ کمترافیک و با امکان بازگشت.
مقدار درست و رابطهاش با ServerLimit
معنی این دستور بسته به MPM فرق میکند و بیشتر پیکربندیهای اشتباه از همینجا میآیند:
- در
preforkهر درخواست یک پروسهٔ مجزا میگیرد، پسMaxRequestWorkersبرابر حداکثر تعداد پروسههاست وServerLimitباید مساوی یا بزرگتر از آن باشد. - در
workerوeventشمارش بر مبنای thread است و سقف واقعی برابرServerLimitضربدرThreadsPerChildاست. اگر عددی بزرگتر بنویسید، آپاچی در لاگ هشدار میدهد و مقدار را خودش پایین میآورد.
برای انتخاب عدد، حافظهٔ مصرفی واقعی یک پروسهٔ آپاچی را روی همان سرور اندازه بگیرید (مثلاً با ps -ylC httpd) و رم آزاد را بر آن تقسیم کنید. عدد بزرگ روی سروری که رم کافی ندارد نتیجهٔ معکوس میدهد و سرور را به swap و سپس OOM میرساند. اگر به سقف منابع رسیدهاید و افزایش این عدد فقط اوضاع را بدتر میکند، مسئله دیگر کانفیگ نیست و باید سراغ سرور فیزیکی اختصاصی یا معماری متفاوتی بروید.
تست کانفیگ، بعد ریاستارت
هرگز سرویس را بدون تست کانفیگ ریاستارت نکنید؛ اگر خطایی مانده باشد آپاچی بالا نمیآید و سایتها پایین میمانند. اول httpd -t یا apache2ctl configtest را اجرا کنید و منتظر پیام Syntax OK بمانید. سپس systemctl reload httpd یا apachectl graceful را ترجیح دهید که درخواستهای در جریان را قطع نمیکند؛ ریاستارت کامل فقط وقتی لازم است که MPM یا ماژولها را عوض کرده باشید.
جمعبندی
به ترتیب این چهار مورد را بررسی کنید: نسخهٔ آپاچی، لود بودن دقیقاً یک ماژول MPM، قرار داشتن دستور در سطح server config و بعد از LoadModule، و همخوانی مقدار با ServerLimit و ThreadsPerChild. در بیشتر موارد همین چهار قدم کافی است. اگر سرور در حالت تولید است، پیش از هر تغییر از فایلهای کانفیگ نسخهٔ پشتیبان بگیرید و تغییرها را در بازهٔ کمترافیک و با امکان بازگشت به نسخهٔ قبلی اعمال کنید.
