Ошибка 503 apache

Website errors always shatter your peace of mind. Especially, when you have no clue on what causes it.

A typical example is Apache 503 error on your website. Unfortunately, the web server just says it as “service unavailable.”

But, the tricky part is finding the real reason that made service unavailable.

That’s why, we often get requests from customers to solve Apache 503 errors as part of our Technical Support Services.

Today, we’ll see how Bobcares’ Engineers solved Apache 503 error for our customer.

More About Apache 503 service unavailable error

Firstly, lets try to understand the important things on Apache 503 error.

A 503 service unavailable error simply means that the server was temporarily unable to handle the request for the website. And, at other times it works perfectly. Therefore, in Apache, this happens when there is temporary overloading. Or, it can be a problem with the applications that process website data.

For example, in PHP based websites, when site requests exceed PHP timeouts, memory limits, etc. it shows the 503 error. Similarly, it can happen when Apache web server is incapable of handling website requests too.

Thus, the underlying reason can vary depending on the actual server setup. And, that’s where our server administration experience helps.

Background of the Apache 503 error

Now, its time to get some background information about the recent request to fix Apache 503 error.

My website runs on a Virtualmin system which hosts 6 websites. 5 of them run flawless. The 6th website (xxx.com) experiences regular timeouts (Error 503 Service Unavailable). Can you fix it please?

That was the exact request from our customer. And, the error showed up as below.

When our Dedicated Engineers checked, we could see that the server was already patched. It had Apache’s processing module set as Prefork.  Also, PHP 5.x was running in FastCGI mode.

Also, we confirmed that the server had enough free resources to support all the websites.

Additionally, the Apache 503 error on the website was intermittent. Mostly, a reload in the browser made the website working again.

How we fixed Apache 503 error

Now, we’ll see how our Support Engineers found the real reason for the service unavailable error and fixed it. This involved multiple steps and let’s see each of them in detail.

1. Checking logs

As always, we began by checking the logs. The error was Apache related. Obviously, the right place was to check the Apache log files at /usr/local/apache/logs. We searched the apache access and error logs with the problem domain name. And, we could see detailed errors related to the website user in the logs as :

[Wed Mar 13 07:37:32.473096 2019] [fcgid:warn] [pid 14628] [client 40.xx.xx.103:5181] mod_fcgid: can't apply process slot for /home/abc/fcgi-bin/php5.fcgi

Additionally, the logs were showing these messages:

[Thu Mar 21 07:02:23.056338 2019] [fcgid:warn] [pid 24842] mod_fcgid: process 10087 graceful kill fail, sending SIGKILL
[Thu Mar 21 07:02:23.056353 2019] [fcgid:warn] [pid 24842] mod_fcgid: process 10083 graceful kill fail, sending SIGKILL

2. Tweaking PHP FCGI parameters

Luckily, in this case the logs gave enough hints about the underlying cause of the Apache 503 error.

Firstly, we began with tweaking the FCGI parameters of the website.  In simple terms, FastCGI is a method for connecting interactive programs with a Apache web server. Apache allows setting Fastcgi limits for each website. Therefore, we increased the parameter “FcgidMaxRequestsPerProcess” value to 500. Additionally, we tweaked related FastCGI parameters too. And, the final configuration file for the website looked as shown below.

IdleTimeout 3600
ProcessLifeTime 7200
IPCConnectTimeout 8
IPCCommTimeout 600
BusyTimeout 300
MaxRequestLen 15728640
FcgidMaxRequestsPerProcess 500 

Again, these values depend on the amount of server resources available for Apache. With a web server restart, we could solve the 503 error and make the website working. However, since the issue was intermittent, we kept on monitoring the website. For this, our Dedicated Engineers configured automatic alerts too. Thus, it helps us to check the server at the time of error.

3. Tweaking Apache

The website was working again. But, that was not enough. We wanted to give a complete solution to the customer. The server logs showed performance issues in Apache. And, that’s why, we suggested customer to change the Multi Processing Module (MPM) of the Apache server too.

The solution was to switch Apache MPM from Prefork to Worker. Prefork is a less efficient MPM. But, the change in MPM is a major web server configuration change, and removes Apache from owning PHP requests. Instead, it needs a separate service named FPM to handle PHP.

Unfortunately, these changes come with a risk of website application failing to work properly with new apache environment of “worker”. Therefore, we scheduled the Apache change in a way that there was enough time to plan things ahead. We made customer check with the website developers of each website about the change in the server environment.

Finally, our Support Engineers proceeded with the task to change Apache MPM to worker at off peak hours. Thus, we could minimize the business impact on the websites. Luckily, the change did not take much time and sites started loading fine.

4. Monitoring Websites

Doing major changes on the Apache web server can have impact on websites. That’s where website monitoring helps. Our Dedicated Engineers kept the server on our watch list and ensured that the server is performing up to the mark. This involves monitoring the server resources, Apache memory usage, etc. on the peak hours as well.

Additionally, we always do load testing on Apache servers to foresee the server performance well in advance.

[Is your Apache websites showing up 503 errors? We can fix it for you.]

Conclusion

In short, Apache 503 error happens mainly when there are problems at the web server settings. But, as 503 error occurs intermittently, the fix can be tricky. Today, we saw how our Support Engineers nailed down the exact reason for Apache 503 error and fixed it for a customer in production server.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Sometimes you may get 503 Service Temporarily Unavailable Error in Apache web server due to various reasons. In this article we will look at what is meant by 503 Service Temporarily Unavailable Error, why it occurs and how to fix 503 Service Temporarily Unavailable Error in Apache.

503 Service Temporarily Unavailable Error in Apache means that your server is unavailable to handle the request, because it is temporarily overloaded or down. It is different from 500 Internal Server error where the server is unable to process the request altogether. In this case, the server is functioning properly but has chosen to return 503 response code.

Bonus Read : How to Redirect and Keep Original URL in Apache

How to Fix 503 Service Temporarily Unavailable Error in Apache

Here is how to fix 503 service temporarily unavailable error in Apache

1. Reboot Apache Server

One of the simplest ways to fix 503 service temporarily unavailable error in Apache is to restart your Apache server. Many times, the server gets overloaded due to too many open connections, or too many temp files. Rebooting your server will help close unwanted connections and delete temporary files causing the bottleneck. If there are multiple servers, make sure to properly restart all of them so that your website/application is completely refreshed.

Bonus Read : How to Fix 500 Internal Server Error in Apache

2. Check for Unexpected Maintenance

Have you scheduled a maintenance to start now? You may not realize it but some of your system applications might be scheduled to be upgraded/updated and they might be automatically downloading & installing updates. That is when Apache may be issuing 503 service temporarily unavailable error. This is very common in CMS based systems such as WordPress, Magento which have auto updates. In such cases, open the system administration/control panel and disable auto-updates or automatic maintenance scheduling.

Bonus Read : How to Install mod_deflate in Ubuntu/CentOS

3.  Server Connectivity

You may also get 503 service temporarily unavailable because one of the servers down the chain might be down or unavailable. Today’s application architecture require multiple servers or even third-party services. If any one of them goes down or is unavailable, then you may see this error.

Bonus Read : How to Fix 504 Gateway Timeout Error in Apache

4. Check Server Logs

Every server logs the incoming request details such as requesting IP, device, requested URL, date-time, and server response. Use any of the server log monitoring tools to find out which requested URLs are receiving 503 service temporarily unavailable error. It may be occurring for some of the URLs and not all requests. In such cases, you can look into the processing of those URLs and identify the underlying cause quickly. If all incoming requests get this error, then it must be a system-wide problem. Either way, server logs will help you diagnose issues quickly.

Bonus Read : How to Check Which Apache Modules are Enabled

5. Application bugs

As a follow up from the previous step, in case your server returns 503 error code only for certain URLs, then look for application bugs or custom code for processing of those URLs. Analyze your version control system (like Git, SVN, etc) for any recent modifications to modules that serve those URLs. This will help you identify the problematic code, and fix it quickly.

Hopefully, the above tips will help you fix 503 service temporarily unavailable error in Apache.

Ubiq makes it easy to visualize data in minutes, and monitor in real-time dashboards. Try it Today!

Время на прочтение
7 мин

Количество просмотров 30K

Работа в поддержке хостинга в основном однотипная, большинство запросов от клиентов решаются по проработанной схеме, но иногда всё же приходится сталкиваться с нетривиальными проблемами. Тогда главная задача инженера — найти тот самый — единственно верный путь, который приведёт к её решению. В этой статье хочу рассказать о том, как мы столкнулись с плавающей ошибкой «HTTP Error 503. Service Unavailable» на нашем shared-хостинге, как пытались её отловить, провели диагностику и получили неожиданный финал.

Начало

Хостинг предоставляет пользователям типичный стек Linux + Apache + Mysql + PHP и оболочку для управления. В нашем случае это ISP Manager 5 business на базе Centos 7 с конвертацией в CloudLinux. Со стороны административной части, CloudLinux предоставляет инструменты для управления лимитами, а так же PHP-селектор с различными режимами работы (CGI, FastCGI, LSAPI).

В этот раз к нам обратился клиент со следующей проблемой. Его сайт на движке WordPress периодически начал отдавать 503 ошибку, о чём он нам и сообщил.

Коды ответа, начинающиеся с 50х, относятся к проблемам на стороне сервера. Это могут быть проблемы как самого сайта, так и веб-сервера, который их обслуживает.

Типичные ситуации, при которых мы получаем следующие ошибки:

• 500 Internal Server Error — довольно часто связана либо с синтаксическими ошибками в коде сайта, либо с отсутствующими библиотеками / не поддерживаемой версией PHP. Так же могут быть проблемы с подключением к базе данных сайта или неверными правами на файлы / каталоги
• 502 Bad Gateway — например, если Nginx ссылается на неправильный порт веб-сервера Apache или процесс Apache по какой-то причине перестал работать
• 504 Gateway Timeout — ответ от Apache не был получен в течение заданного в конфигурации веб-сервера времени
• 508 Resource limit is reached — превышен лимит, выделяемых пользователю ресурсов

В данном списке приведены лишь некоторые, наиболее распространённые случаи. Также стоит отметить, что при превышении лимитов пользователь может получить как 500, так и 503 ошибку.

При выполнении диагностики данных ошибок, первым делом проверяем журналы веб-сервера. Обычно, этого достаточно, чтобы определить виновника и исправить проблему.

Касаемо 503 ошибки в нашем случае, в логах мы видели запись:

[lsapi:error] [pid 49817] [client x.x.x.x:6801] [host XXX.XX] Error on sending request(GET /index.php HTTP/1.0); uri(/index.php) content-length(0): ReceiveAckHdr: nothing to read from backend (LVE ID 8514), check docs.cloudlinux.com/mod_lsapi_troubleshooting.html

На основании только этого лога, определить в чём может быть проблема не представлялось возможным.

Первичная диагностика

Изначально, мы проверили статистику превышения лимитов пользователем. Незначительные превышения были зафиксированы за предыдущие дни, но ошибки в журналах были свежие, более того они появлялись в журнале с периодичностью от одной до нескольких минут.

Так же мы изучили рекомендации CloudLinux, по приведённой в журналах ошибок ссылке.
Изменение каких-либо параметров результата не принесло.

Сайт использовал базу данных на сервере Mysql 5.7, который работает на этом же сервере в контейнере Docker. В логах контейнера присутствовали сообщения:

[Note] Aborted connection 555 to db: 'dbname' user: 'username' host: 'x.x.x.x' (Got an error reading communication packets)

Как раз, среди этих сообщений были сообщения о прерванном подключении исследуемого сайта. Это дало предположение, о том, что подключение к СУБД выполняется некорректно. Для проверки мы развернули копию сайта на тестовом домене, сконвертировали базу данных сайта под нативную в Centos 7 версию СУБД 5.5.65-MariaDB. На тестовом сайте выполнили несколько сотен запросов с помощью утилиты curl. Ошибку воспроизвести не удалось. Но этот результат был предварительным и после конвертации БД на рабочем сайте проблема так и осталась.

Таким образом, проблема некорректного подключения к СУБД была исключена.

Следующим предположением было проверить — нет ли проблем с самим сайтом. Для этого подняли отдельный виртуальный сервер, на нём подняли максимально схожее окружение. Единственное существенное отличие — отсутствие CloudLinux. На тестовом сервере проблему воспроизвести не удалось. Итак, мы определили, что в коде сайта всё в порядке. Тем не менее, пробовали так же отключать плагины WordPress, но проблема так же сохранялась.

В результате, пришли к тому, что проблема на нашем хостинге.

В ходе анализа журналов других сайтов было обнаружено, что проблема наблюдается на многих из них. Порядка 100 шт. на момент проверки:

/var/www/httpd-logs# grep -Rl "ReceiveAckHdr: nothing to read from backend" ./ | wc -l
99

В ходе тестирования обнаружили, что только что установленная чистая CMS WordPress также периодически выдаёт ошибку 503.

Примерно за 2 месяца до этого мы проводили работы по модернизации сервера, в частности изменили режим работы Apache с Worker на Prefork, с целью получить возможность использовать PHP в режиме LSAPI, вместо медленного CGI. Было предположение, о том, что это могло повлиять, либо требуются какие-то дополнительные настройки Apache, но вернуть обратно режим Worker мы уже не могли. В ходе изменения режима работы Apache выполняется изменение всех конфигов сайтов, процесс не быстрый и не всё могло пройти гладко.

Корректировка настроек Apache так же не дала желаемого результата.

Попутно искали схожие проблемы в поисковых системах. На одном из форумов участники утверждали, что проблема у хостера и нужно его менять, если проблему не решают. Звучит не очень оптимистично, когда ты находишься с другой стороны, но и клиента понять можно. Зачем ему нерабочий хостинг.

На данном этапе мы собрали имеющуюся информацию и результаты проведённых работ. С ними обратились в поддержку CloudLinux.

Детальная диагностика

В течение нескольких дней сотрудники поддержки CloudLinux вникали в проблему. В основном рекомендации были относительно установленных лимитов пользователей. Этот вопрос мы так же проверяли. При отключенных лимитах (Опция CageFS для пользователя) и с включенными лимитами в режиме PHP как модуль Apache проблема не наблюдалась. Исходя из этого, было сделано предположение, что каким-то образом оказывает влияние CloudLinux. В итоге, к концу недели запрос был эскалирован на 3-ий уровень поддержки, но решения пока не было.

Попутно изучали документацию Apache по режимам работы CGI и LSAPI, подняли второй экземпляр Apache на сервере хостинга на другом порту с тестовым сайтом, исключили влияние Nginx, отправляя запросы напрямую к Apache и получая те же коды ошибок.

Сдвинуться с мёртвой точки помогла документация LSAPI, как раз по диагностике 503 ошибки:
www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:php:503-errors
В секции Advanced Troubleshooting предлагается выполнять трассировку найденных в системе процессов:

while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep $SCRIPTNAME | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid; fi ; done

Команда была доработана, с целью записи всех процессов в файлы с указанием их идентификаторов.

При просмотре файлов трассировок, мы видим в некоторых одинаковые строки:

cat trace.* | tail
...
47307 21:33:04.137893 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=42053, si_uid=0} ---
47307 21:33:04.140728 +++ killed by SIGHUP +++
...

Если взглянуть на описание структуры сигналов, отправляемых процессами, то увидим, что

pid_t    si_pid;       /* Sending process ID */

Указывает на идентификатор процесса, отправившего сигнал.

На момент изучения трассировок, процесса с PID 42053 в системе уже нет, поэтому в процессе захвата трассировок решили отслеживать так же процессы, отправившие сигнал SIGHUP.
Под спойлером описаны действия, которые позволили определить что это за процесс, а так же получить его трассировку и дополнительную информацию, о том, каким процессам он отправляет сигнал SIGHUP.

tail -f /var/www/httpd-logs/sitename.error.log

while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep "sitename" | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid -o /tmp/strace/trace.$mypid; fi ; done

while true; do if mypid=`cat /tmp/strace/trace.* | grep si_pid | cut -d '{' -f 2 | cut -d'=' -f 4 | cut -d',' -f 1`; then ps -aux | grep $mypid; fi; done;

seq 1 10000 | xargs -i sh -c "curl -I http://sitename/"

В итоге, получили название процесса /opt/alt/python37/bin/python3.7 -sbb /usr/sbin/cagefsctl --rebuild-alt-php-ini

Данный процесс выполнялся в системе с периодичностью раз в минуту.

Делаем трассировку нескольких процессов cagefsctl, чтобы отследить хотя бы один от начала до конца:

for i in `seq 1 100`; do strace -p $(ps ax | grep cagefsctl | grep rebuild-alt-php-ini | grep -v grep | awk '{print $1}') -o /tmp/strace/cagefsctl.trace.$(date +%s); done;

Далее изучаем что он делал, например:

cat /tmp/strace/cagefsctl.trace.1593197892 | grep SIGHUP

Так же были получены идентификаторы процессов, которые были завершены сигналом SIGHUP. Завершённые процессы были процессами PHP, выполняющимися в данный момент.

Полученные данные были переданы в поддержку CloudLinux с целью уточнить легитимность данного процесса и должен ли он работать с такой периодичностью.

Позже получили ответ, что работа команды /usr/sbin/cagefsctl --rebuild-alt-php-ini выполняется корректно, единственный нюанс в том, что команда выполняется слишком часто. Обычно вызывается при системном обновлении или изменении параметров PHP.

Единственная зацепка в данном случае осталась — проверить, кто является родительским процессом cagefsctl.

Результат не заставил себя долго ждать и какого же было наше удивление — родительским процессом для cagefsctl являлся процесс ispmgrnode. Это было немного странно, потому что уровень журналирования для ISP Manager был задан максимальным и в ispmgr.log не увидели вызов cagefsctl.

Теперь данных было достаточно, чтобы обратиться и в поддержку ISP System.

Итоги

Проблема была спровоцирована после выполнения обновления ISP Manager. В целом, обновление ISP Manager — штатная ситуация, но она привела к запуску процесса синхронизации, который завершался с ошибкой и перезапускался ежеминутно. Процесс синхронизации вызывал за собой процесс cagefsctl, который в свою очередь завершал процессы PHP.

Причиной зависания процесса синхронизации стали проведённые на хостинге работы по модернизации оборудования. За несколько месяцев до возникновения проблемы, в сервер был установлен PCI-e NVMe-накопитель, создан раздел XFS и смонтирован в каталог /var. На него были перенесены в том числе и файлы пользователей, но не обновились дисковые квоты. Опций монтирования было не достаточно, требовалось так же изменить тип файловой системы в параметрах ISP Manager, т.к. она вызывает команды обновления дисковых квот. Для Ext4 и XFS эти команды отличаются.

Таким образом, проблема дала о себе знать спустя несколько месяцев после проведения работ.

Выводы

Мы сами создали проблему, но это было не ясно до последнего момента. На будущее, будем стараться учесть как можно больше нюансов. Благодаря помощи более подготовленных коллег из поддержки CloudLinux и ISP System, проблема была решена. Теперь наш хостинг работает стабильно. А нами был получен опыт, который пригодится нам в будущей работе.

P.S.: Надеюсь, Вам было интересно ознакомиться с материалом статьи, а кому-нибудь она поможет быстрее решить подобную проблему.