HTTP ERROR 500 and all sites on server down

[spiros]

I had the above issue, then posted a ticket on Cpanel, and they came with this weird reply that SMF 2 does not support php 7.1. In fact, the issue affected all sites on the server, not just SMF

It seems your Simple Machines Forums software (SMF) on the X account is not PHP 7.1 compatible.

As a test, I switched the PHP version from 7.1 to 5.6 and the site works now.

You'll need to consult with the authors of SMF if PHP 7.1 is not working as expected. The error I saw as:

[14-Feb-2019 20:41:24 UTC] PHP Parse error: syntax error, unexpected ''$string, '' (T_CONSTANT_ENCAPSED_STRING), expecting ';' in Load.php(257) : runtime-created function on line 2

That's a coding error in the script itself. I assumed it was that the mbstring function was not installed for PHP 7.1, but I checked that and it is.

[22:43:19 host root@11434833 public_html]cPs# scl enable ea-php71 'php -m | grep mbstring'
mbstring

More here: https://forums.cpanel.net/threads/http-error-500-on-all-server-sites.647469/

[vbgamer45]

All your sites down? SMF 2.0.15 supports PHP 7.1

[Illori]

a mod may not support php 7.1, you would need to check that line to see if a mod added it or not.

[spiros]

Yeah, all sites were down, but I am not so sure that SMF was the culprit, how could it be when different domains were down?

Here the line 257 from load.php, line 2 is just empty space after the <?php bit.

Code Select Expand

'strtoupper' => $utf8 ? (function_exists('mb_strtoupper') ? create_function('$string', '
return mb_strtoupper($string, \'UTF-8\');') : create_function('$string', '
global $sourcedir;
require_once($sourcedir . \'/Subs-Charset.php\');
return utf8_strtoupper($string);')) : 'strtoupper',


[drewactual]

increase your mpm workers, and/or increase your TTL on those workers to at least 5 (seconds). 

there is also an apache mod, can't recall its name off top of my head, but it will dynamically increase workers as needed. 

i too run mpm, but in an FPM environment and i haven't bumped to 7.1 yet (still at 7.0.33), but i'm not sure it's the best environment for our purposes... the reason i used it is due to the permissions (allowing anonymous as user as opposed to 'just' nobody, which really REALLY taxed me trying to figure out why things clogged up on the error log).

and another for what it's worth: my dedicated server has also been beat up over the last few days- it appears access has been attempted on server level scripts i've either blocked or locked down tight.  this isn't anything new, but what is new is that whatever this action does results in an apache hiccup and a generation to close and another re-opened.  you can see this under WHM 'server status' and 'apache status', and in the first paragraph beside 'parent server generation' and 'mpm generation' below it.  you really don't want to see multiple generations unless its cause is obvious such as an update ran..

the number of workers available, i think, defaults at something like 10.  that is way too low.  it takes some math to determine what is best and is based on RAM and processor power.  for what it's worth, i set mine at workers:125, which that mod i spoke of almost immediately reduces to 100, but i've never seen more than 15 being used at any given time (in current config)- and this is with 100 concurrent users on the page.  i set the TTL at 5 seconds.. i think default is actually 0, meaning the door opens and closes as the worker does what's asked instead of holding the door open for five seconds in the case of subsequent requests.  more than 10 seconds is overkill i'm thinking, as the only time there have been more than 10 workers occupied ever was when it touched i think it was 55 workers... the server withstood it, but as soon as things quieted down i set the TTL to 5 and it hasn't broke the 15 occupied workers since.   

by the way- i think the FPM is required for the mod i speak of... it also can be set to increase workers dynamically if needed.

mpm works, don't get me wrong- but it occupies a lot of RAM even when idle, which will slow response down a bit- the other 'types' don't do this- they operate as needed- the drawback on them for our purposes is when there is heavy traffic everyone slows down.  with MPM there is an outside chance somebody is going to be rejected, but for those occupying a worker? they're not going to notice any performance issues at all- it'll be the same as any other day/moment when there isn't heavy traffic... 100 people clicking something at the precise same moment may be a concern for massive websites- but it sure isn't for mine.  like i said, concurrent users according to analytics in the 125~150 range and still no more than 15 occupied workers at the same time.   

[Arantor]

Why would increasing MPM workers, or lack of them, produce a 500? I could see lack of workers producing 502 or possibly 504, but FPM shouldn't be generating a 500 for anything outside of configuration failure, failure to initialise and/or failure in the PHP script.

[drewactual]

It may have been a 502 I saw.. I dont recall that though... His error logs on the link suggest mpm workers is why I offered.