Issue Intermittent 503 Errors on Plesk Obsidian (Ubuntu 22.04 LTS) with PHP-FPM Crashes - Seeking Advice

[brother4]

Server operating system version

Ubuntu 22.04

Plesk version and microupdate number

18.0.63 Update #4

Hello everyone,

I’ve been experiencing intermittent issues where certain domains on my Plesk Obsidian (Ubuntu 22.04 LTS) instance go offline with the following error:

503 Service Unavailable

Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

The automated website log checker (Plesk solution) doesn’t find any errors for the currently affected domain.

However, this is what I do see:

root@1234:~# tail -f /var/log/plesk-php82-fpm/error.log
[24-Sep-2024 08:42:28] WARNING: [pool example.com] child 1448468 exited on signal 11 (SIGSEGV) after 4.410661 seconds from start
[24-Sep-2024 08:42:53] WARNING: [pool example.com] child 1448514 exited on signal 11 (SIGSEGV) after 0.036528 seconds from start
[24-Sep-2024 08:42:57] WARNING: [pool example.com] child 1448515 exited on signal 11 (SIGSEGV) after 4.098674 seconds from start

root@1234:~# tail -f /var/www/vhosts/system/example.com/logs/error_log
[Tue Sep 24 14:17:37.220031 2024] [proxy_fcgi:error] [pid 1446543:tid 139694425372224] [client 92.217.248.57:0] AH01067: Failed to read FastCGI header
[Tue Sep 24 14:17:37.220090 2024] [proxy_fcgi:error] [pid 1446543:tid 139694425372224] (104)Connection reset by peer: [client 92.217.248.57:0] AH01075: Error dispatching request to :
[Tue Sep 24 14:17:53.889554 2024] [proxy_fcgi:error] [pid 1446543:tid 139694163596864] [client 92.217.248.57:0] AH01067: Failed to read FastCGI header
[Tue Sep 24 14:17:53.889627 2024] [proxy_fcgi:error] [pid 1446543:tid 139694163596864] (104)Connection reset by peer: [client 92.217.248.57:0] AH01075: Error dispatching request to :
[Tue Sep 24 14:26:29.016369 2024] [proxy_fcgi:error] [pid 1446543:tid 139693475755584] [client 91.7.236.123:0] AH01067: Failed to read FastCGI header
[Tue Sep 24 14:26:29.016409 2024] [proxy_fcgi:error] [pid 1446543:tid 139693475755584] (104)Connection reset by peer: [client 91.7.236.123:0] AH01075: Error dispatching request to :

My PHP-FPM settings are on the Plesk default (ondemand, etc.). A memory diagnostic didn’t return any errors. The server was not under more than 25% CPU load throughout the days and still had several GB of RAM available.

Do you have any ideas what could be causing this?

I’ve found content such as this Plesk support article (Website page is not accessible with 503 error: Service Temporarily Unavailable - Support Cases from Plesk Knowledge Base), but it references RHEL 8 and Imagick issues, which were fixed with patches in May and June 2023, so it doesn’t seem to apply here.

This issue occurs randomly, only every few days, and affects different domains each time.

Any ideas on what might be causing this?

Thanks a lot!

 

[ChristophRo]

If you have used the Plesk Performance Booster I recommend to disable the PHP 8.x Jit compiler settings again for these sites.
I've seen way to many of these random "child xxx exited on signal 11 (SIGSEGV)" errors with Jit enabled, that appear suddenly after a couple hours, days or even weeks. (and will go away after a php-fpm service restart...until they resurface again)

 

[afuego]

Hi @brother4

I saw this article too, it mentions as possible cause' Incompatibility between the PHP interpreter and website code

https://support.plesk.com/hc/en-us/articles/12389254411159-Some-pages-of-the-web-site-returns-503-error-child-exited-on-signal-11-SIGSEGV

 

[brother4]

@ChristophRo
I do not use the Plesk Performance Booster, or at least I have not activated it via panel.ini, as described here: (Plesk for Linux) Website Performance Optimization
Could there still be problems here? I mean the problems also existed before I configured the PHP 8.2 JIT compiler.

@afuego
But if this problem were true, shouldn't it actually work sometimes and sometimes not? For example, I just got the error initially when I tried to access the WordPress backend. After two refreshes it worked again.

Even with very simple small PHP scripts that are definitely compatible with PHP 8.2 and 8.3 and do not include anything else, the problem persists from time to time. I therefore rule out errors in the code. Something else seems to be causing instability.