Hi cPrex
No, there are this lines in error.log before and after:
[Sun Feb 13 08:03:44.206893 2022] [http2:warn] [pid 9606:tid 47100683740224] AH10291: h2_workers: cleanup, 1 idle workers did not exit after 5 seconds.
[Sun Feb 13 08:14:49.702043 2022] [mpm_event:notice] [pid 2739:tid 47100683740224] AH00493: SIGUSR1 received. Doing graceful restart
But we have updated apache and the patch should be included:
Jan 03 05:18:14 Updated: ea-apache24-2.4.52-2.2.1.cpanel.x86_64
Jan 14 01:23:53 Updated: ea-apache24-2.4.52-2.2.2.cpanel.x86_64
Feb 08 18:48:33 Updated: ea-apache24-2.4.52-3.3.1.cpanel.x86_64
So for me the behavior sounds like the apache problem and I think the patch didn't work as 100%. Maybe there are some conditions that make apache unresponsive.
No, there are this lines in error.log before and after:
[Sun Feb 13 08:03:44.206893 2022] [http2:warn] [pid 9606:tid 47100683740224] AH10291: h2_workers: cleanup, 1 idle workers did not exit after 5 seconds.
[Sun Feb 13 08:14:49.702043 2022] [mpm_event:notice] [pid 2739:tid 47100683740224] AH00493: SIGUSR1 received. Doing graceful restart
But we have updated apache and the patch should be included:
Jan 03 05:18:14 Updated: ea-apache24-2.4.52-2.2.1.cpanel.x86_64
Jan 14 01:23:53 Updated: ea-apache24-2.4.52-2.2.2.cpanel.x86_64
Feb 08 18:48:33 Updated: ea-apache24-2.4.52-3.3.1.cpanel.x86_64
So for me the behavior sounds like the apache problem and I think the patch didn't work as 100%. Maybe there are some conditions that make apache unresponsive.
Thank for that - that looks like normal Apache restart behavior to me, but if it's happening more frequently than you expect can you please submit a ticket to our team so we can check that directly on the affected server?
Hey just wanted to reply here, we've got about 10 fully patched WHM/cpanel servers all running on Centos 7 and we've been battling these symptoms since Friday Feb 11th on JUST one server. All others are fine. We are running the latest ea-apache24-2.4.52-3.3.1.cpanel.x86_64 and have tried everything we know to stop these apache service drops. Ours are actually happening in the mornings only at pretty regular times and are unrelated to load or external attacks as far as we can tell. Apache just dies and a restart fixes it. No load ever at these events. We're logging netstat output every minute AND scouring all mod_security logs for anything just before these events. We've had about 4 per day for 7 days now. We've got a 1 minute cron job that restarts apache when it sees it go down (via url check) so symptoms are mildly handled for now.
I totally get that this issue affected 1.1.3 and was fixed in 2.2.1 but Im pretty sure we're seeing this issue as well. We do not see this issue on our 9 other whm hosts running the same version of ea-apache24.
I can open a ticket just wondering if anyone other than @roliboli and I are experiencing this. We've got two senior devops admins that have been battling this all week so we're sure it's not something simple being overlooked. Thanks a million for any assistance you can provide.
Our error log shows the same thing as @roliboli as well, nothing noting why apache stops responding.
Thanks
Chris
I totally get that this issue affected 1.1.3 and was fixed in 2.2.1 but Im pretty sure we're seeing this issue as well. We do not see this issue on our 9 other whm hosts running the same version of ea-apache24.
I can open a ticket just wondering if anyone other than @roliboli and I are experiencing this. We've got two senior devops admins that have been battling this all week so we're sure it's not something simple being overlooked. Thanks a million for any assistance you can provide.
Our error log shows the same thing as @roliboli as well, nothing noting why apache stops responding.
Thanks
Chris
We also continue to experience the same issue even after patching back in Jan. Currently running 2.4.52-3. Just as the others have described there's nothing in the Apache error log nor is there any sign of an attack. The Apache service will be running, but there will be no active processes and trying to view the Apache status will timeout.
We did open a support ticket and the tech suggested switching to prefork. Not really thrilled about making that switch, so just wondering what anyone else experiencing this has done.
We did open a support ticket and the tech suggested switching to prefork. Not really thrilled about making that switch, so just wondering what anyone else experiencing this has done.
Since the patch, i didn't have any more issues in multiple servers.
Maybe that issue is other not related with this one?
It's always possible there could be a separate issue as @DJPRMF mentioned. @njslnetops - could you post that ticket number so I can follow along?
@njslnetops -It looks like your server has been updated since we checked the ticket, as I do see the system is running Apache 2.4.53 now. UPS-421 is still the correct case for the 2.4.52 issue, but that has been fixed.
I do see some issues with your server updates though, which you can see by running "yum update" on the machine, so you'll want to look into that and get those resolved to ensure you are getting updates in the future.
I also see your update tier is pinned directly to "94" instead of "LTS" so you aren't receiving all the updates you could. You may also want to change that as well, although version 102 will likely be moving to the LTS tier at some point this year.
I do see some issues with your server updates though, which you can see by running "yum update" on the machine, so you'll want to look into that and get those resolved to ensure you are getting updates in the future.
I also see your update tier is pinned directly to "94" instead of "LTS" so you aren't receiving all the updates you could. You may also want to change that as well, although version 102 will likely be moving to the LTS tier at some point this year.
Yes, I see that Apache has been updated. I don't see any related fixes to our issue in the release notes, but here's hoping it resolves our issue.
Thanks for the additional insight, I'll take a look at those update issues.
The switch to 94 is intentional so that we can control when 102 gets installed. This LTS update cycle in particular has several UI changes that could be disruptive for our users. We do plan to be on 102 before the June 30th end of support for 94.
Thanks for the additional insight, I'll take a look at those update issues.
The switch to 94 is intentional so that we can control when 102 gets installed. This LTS update cycle in particular has several UI changes that could be disruptive for our users. We do plan to be on 102 before the June 30th end of support for 94.
I thought v102 might be why that was configured the way it was, but just wanted to point that out just in case!
