Issue 502 bad gateway every day at midnight (caught SIGWINCH, shutting down gracefully)

[Deleted member 209767]

Server operating system version

AlmaLinux

Plesk version and microupdate number

latest

We have recently moved some websites to a fresh new server from CentOS to AlmaLinux. We didn't have any issues before, but on the new server, we are getting 30 email alerts every day at exactly midnight because the cron jobs are failing with 502 Bad Gateway errors. It always happens at exactly 00:00 every day, for the last 3 months.

There are no daily cron jobs running at the same time and nothing that I can think of that would overload the server at midnight. In the monitoring graphs, I can't see anything abnormal, there is not any spike in CPU usage, processes, or memory.

I see in the /var/log/httpd/error.log that the apache server restart around the 00:00

[Wed Apr 19 00:00:00.172327 2023] [mpm_event:notice] [pid 3960165:tid 3960165] AH00492: caught SIGWINCH, shutting down gracefully

What could be causing this? I know I can disable the email alerts, but I'd rather find the underlying issue.

 

[jradzuweit]

Hi,
did you checked your Apache settings "Tools &Settings -> Apache Web Server Settings"? You can force Apache to restart
Also check your cron settings in "Scheduled Tasks" in my installation there are some maintenance tasks(mainly log rotation, cache cleaning etc.) running at 0:00

 

[Deleted member 209767]

did you checked your Apache settings "Tools &Settings -> Apache Web Server Settings"? You can force Apache to restart

I use the default settings, same as our other servers which doesn't have any problem

Also check your cron settings in "Scheduled Tasks" in my installation there are some maintenance tasks(mainly log rotation, cache cleaning etc.) running at 0:00

I don't see any cron job related to logrotate, but for every single other cron job in the Scheduled Tasks, I changed the time, so there are no cron jobs running at 00:00 as far as I know

 

[Deleted member 209767]

We are still having this problem every day at midnight

Every day we receive many emails alerts like that, always at exactly 6:00PM in my timezone, which equals to midnight in server's time


I think logrotate restart the apache daemon



How can i change the time that logrotate runs?

 

[Peter Debik]

Have you tried to set the restart interval to at least 60 seconds and on servers with many domains to rather something long like 600 seconds? Else one reload could be disturbed by another which can cause a hard restart instead of a graceful restart (reload). That again will make Apache unavailable until it stops-starts.

 

[Deleted member 209767]

Yes, the interval is currently set to 1800 seconds. 10 domains are hosted on this server.

 

[Peter Debik]

I was asking because in your first screenshot it was set to zero.
Now with the new setting of 1800, does the issue still occur?

 

[Deleted member 209767]

Yes we tried with zero, 60, and 1800, but the same issue still occurs every day

 

[Deleted member 209767]

We now have this problem on 3 different server. On each of them, it started exactly the day when we migrated from CentOS to AlmaLinux. Before that, we couldn't upgrade Plesk because we were running on unsupported CentOS version. So it looks like the newer Plesk version is responsible for this issue (or AlmaLinux)

 

[Maarten]

Does your server have a static or a dynamic IP address? Dynamic IP addresses can lead to unpredictable issues.

 

[Deleted member 209767]

It's a dedicated server from OVH with a static IP

 

[Esperio]

We now have this problem on 3 different server. On each of them, it started exactly the day when we migrated from CentOS to AlmaLinux. Before that, we couldn't upgrade Plesk because we were running on unsupported CentOS version. So it looks like the newer Plesk version is responsible for this issue (or AlmaLinux)

it is not related with os. It is happening to us either and we are still using centos in one machine

 

[MartinT]

Maybe it is a IP Issue. ModSec / Fail2Ban etc can cause 502 errors. Check the banned IPs and trusted IPs so that the IP of the cronJob is trusted.