Question

Apache crashing linked to MaxRequestWorkers?

Posted on August 4, 2015
Apache
Asked by trg

Hi. I’m wondering if someone can help me solve a problem with my Ubuntu 14.04 server running Apache, PHP, MySQL and phpmyadmin. On the webserver, I’m running an IPB 3.4 forum. It had perfect uptime for around 5 months with no issues until a few days ago when Apache crashed unexpectedly. On every restart, apache will work for a few minutes, then crash with the same message.

The error log tells me to raise MaxRequestWorkers setting, but I changed it and the error still persists. I edited it via “/etc/apache2/mods-enabled/mpm_prefork.conf”, is that the correct place to do so, or is there a different place to edit it?

Any assistance on this issue would be great, I’ll put the last few lines of the Apache error log at the end of this post. Thank you!

[Mon Aug 03 15:00:52.167824 2015] [core:warn] [pid 3045] AH00045: child process 3651 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.167944 2015] [core:warn] [pid 3045] AH00045: child process 3664 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.167956 2015] [core:warn] [pid 3045] AH00045: child process 3690 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.167972 2015] [core:warn] [pid 3045] AH00045: child process 3666 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.168029 2015] [core:warn] [pid 3045] AH00045: child process 3672 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.168046 2015] [core:warn] [pid 3045] AH00045: child process 3673 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.168379 2015] [core:warn] [pid 3045] AH00045: child process 3711 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234635 2015] [core:warn] [pid 3045] AH00045: child process 3486 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234705 2015] [core:warn] [pid 3045] AH00045: child process 3595 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234723 2015] [core:warn] [pid 3045] AH00045: child process 3610 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234737 2015] [core:warn] [pid 3045] AH00045: child process 3616 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234750 2015] [core:warn] [pid 3045] AH00045: child process 3619 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234762 2015] [core:warn] [pid 3045] AH00045: child process 3632 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234773 2015] [core:warn] [pid 3045] AH00045: child process 3635 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234786 2015] [core:warn] [pid 3045] AH00045: child process 3651 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234799 2015] [core:warn] [pid 3045] AH00045: child process 3664 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234861 2015] [core:warn] [pid 3045] AH00045: child process 3690 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234874 2015] [core:warn] [pid 3045] AH00045: child process 3666 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234899 2015] [core:warn] [pid 3045] AH00045: child process 3672 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234917 2015] [core:warn] [pid 3045] AH00045: child process 3673 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.234929 2015] [core:warn] [pid 3045] AH00045: child process 3711 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.497612 2015] [core:warn] [pid 3045] AH00045: child process 3616 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.497688 2015] [core:warn] [pid 3045] AH00045: child process 3619 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.497723 2015] [core:warn] [pid 3045] AH00045: child process 3635 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.497743 2015] [core:warn] [pid 3045] AH00045: child process 3651 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.497786 2015] [core:warn] [pid 3045] AH00045: child process 3666 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.497804 2015] [core:warn] [pid 3045] AH00045: child process 3672 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.497818 2015] [core:warn] [pid 3045] AH00045: child process 3673 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:52.497831 2015] [core:warn] [pid 3045] AH00045: child process 3711 still did not exit, sending a SIGTERM
[Mon Aug 03 15:00:53.500161 2015] [mpm_prefork:notice] [pid 3045] AH00169: caught SIGTERM, shutting down
[Mon Aug 03 15:01:05.467881 2015] [mpm_prefork:notice] [pid 1001] AH00163: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.7 configured -- resuming normal operations
[Mon Aug 03 15:01:05.474812 2015] [core:notice] [pid 1001] AH00094: Command line: '/usr/sbin/apache2'
[Mon Aug 03 15:02:32.958854 2015] [mpm_prefork:error] [pid 1001] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

Show comments

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

KFSys

Site Moderator

• June 15, 2023

Pinned Answer

Heya,

Apart from making sure your system is up to date:

apt update
apt upgrade

you can try increasing the workers.

Your Apache server seems to be hitting the MaxRequestWorkers limit, which means it’s running out of workers to handle incoming requests. This can happen if your server is under heavy load or if there are long-running PHP scripts that are not terminating as expected.

The MaxRequestWorkers directive sets the limit on the number of simultaneous requests that will be served. When this limit is reached, additional incoming connections will be queued, which can lead to slow performance and, eventually, server crashes if not managed properly.

You mentioned that you modified the MaxRequestWorkers setting in the /etc/apache2/mods-enabled/mpm_prefork.conf file. This is the correct location to modify this setting when using the prefork MPM (Multi-Processing Module).

Increase MaxRequestWorkers:

If you haven’t already, try increasing MaxRequestWorkers. Note that the appropriate value for this directive greatly depends on the resources available on your server. Having a very high MaxRequestWorkers setting can lead to your server running out of memory and starting to swap, which can degrade performance significantly.
Check ServerLimit:

Also, the ServerLimit directive sets the maximum configured value for MaxRequestWorkers for the lifetime of the Apache process. The ServerLimit value should be as large as (or larger than) MaxRequestWorkers.

Make sure that your ServerLimit directive is at least as large as your MaxRequestWorkers directive. If not, increase it.

Here is an example of what the mpm_prefork.conf file may look like:

<IfModule mpm_prefork_module>
    StartServers              5
    MinSpareServers           5
    MaxSpareServers          10
    MaxRequestWorkers        150
    ServerLimit              150
    MaxConnectionsPerChild   0
</IfModule>

In this example, MaxRequestWorkers and ServerLimit are both set to 150.
Restart Apache:

After making changes, restart the Apache server:

sudo service apache2 restart

Investigate Long-Running PHP Scripts:

If Apache is still crashing after increasing MaxRequestWorkers and ServerLimit, you should investigate whether any of your PHP scripts are causing the issue. It could be that some of your scripts are taking a long time to execute and thus occupying Apache workers longer than they should.
Upgrade Your Server:

If your server is consistently hitting the MaxRequestWorkers limit and you have already optimized your PHP scripts, it might be time to consider upgrading your server or adding additional servers to handle the load.

Remember, changes to these settings need to be done with careful consideration of your server’s resources, such as RAM and CPU, because raising MaxRequestWorkers or ServerLimit too high could potentially use up all available system resources and crash the server.

As for the message about the child process not exiting, that’s usually due to an Apache worker that’s stuck for some reason. This could be due to a long-running PHP script or a connection that isn’t closing properly. It’s hard to say for certain without more information. Apache will try to handle this situation by sending a SIGTERM signal to the process, but if it doesn’t exit, it may need to be debugged to find the cause.

evtol1 • August 21, 2022

Had the same issue. I use fpm service and after restarting works as expected. The command I used to restart it was: sudo systemctl restart php7.2-fpm.service

Youssef Karami • February 17, 2017

I was able to fix it by issuing an upgrade command