Http 500 code, moved server, can't install! Help!

[Dinky]

Hi all,

MY existing forum is 2.0.17. In the last few days since my host helpfully upgraded PHP to v8, I'm now getting 500 error codes. I can't fixed a shared server so I decided to move it over to my small VPS.

I moved the forum files and the database, changed the login details in settings.php and it crashed the apache service repeatedly. I disabled eaccelerator and that made no difference, the error message changed but it still crashed.

So i downloaded a clean version of 2.0.17 and decided to install that.

Requirements page says:
2.0-2.0.6   4.1-5.4
2.0.7-2.0.13   4.1-5.6
2.0.14-2.0.15   5.4-7.1
2.0.16-2.0.17   5.3-7.3  <==
2.0.18-2.0.18   5.3-7.4
2.0.19-2.0.19   5.3-8.0

Interestingly an earlier version up to 2.0.15 requires a later version of php but a later version is good with an earlier version of php?

Anyway, my version of PHP is 5.3.6

Requirements page says: MySQL 4.0.18 or higher (at least 4.1.0 would be better) and PHP MySQL client API 4.0.18 or higher.

I have mysqlnd 5.0.8-dev

When I run install.php and I get this:

Critical Error!
The version of your database server is very old, and does not meet SMF's minimum requirements.

Urgh... yes it does?

So what gives? How do I get my forum back online given that my apache, php and mysql exceed the stated minimum requirements?

Thanks

D

[Kindred]

1- use a modern, supported version of php...
Just because we have legacy support does not mean that it is recommended


2- upgrade to 2.0.19

[Dinky]

I would upgrade if i knew my old database would work with it. On most forums you have a forums you have a working setup and then upgrade it. Upgrading a dead version is opening the proverbial tin.

Anyway I've got the fresh version working by doing this in install.php

Code Select Expand

// if (version_compare($databases[$db_type]['version'], preg_replace('~^\D*|\-.+?$~', '', eval($databases[$db_type]['version_check']))) > 0)
// {
// $incontext['error'] = $txt['error_db_too_low'];
// return false;
// }

That got me past the version check.. tomorrow i'll swap databases about and see what happens.

[Kindred]

There are no database changes in 2.0.x

Even if you upgraded to 2.1.x (which is recommended), the upgrade process converts the database to the needed formats

[Dinky]

Right, i've deleted all the new tables and copied the current forum database tables into the database instead.

Now the crash is back.

What gives?

[Tue Sep 26 10:20:04 2023] [notice] Parent: child process exited with status 3221225477 -- Restarting.

If I re-enable eaccelerator then that message changes back to:

*** UnKnown can't find 127.0.0.1: Not implemented

[Tue Sep 26 10:24:03 2023
] [notice] EACCELERATOR(12580): PHP crashed on opline 11 of {closure}() at C:\UniServer\vhosts\ducks2\www\Sources\QueryString.php:493

[Tue Sep 26 10:24:04 2023] [crit] Parent: child process exited with status 3 -- Aborting.

[Kindred]

it looks like you have a badly configured database connection.

Use repair_settings.php to correct the database connection details, paths and URLs for your moved forum....

[Dinky]

Well that settings_repair.php white screened me too.. error log grumbled about unexpected '[' so I changed all the [] to array() - hopefully that helps someone in the future.

Now i've run it and it did indeed find some urls and system paths still pointing to the previous hosts locations. I've updated those.. but the site STILL crashes.

The username and password for the database ARE correct. I've not changed them.

The fresh install worked. I removed those tables and put the original ones back and it crashes. This is since the host at the old site upgraded.

What am I looking for? - It's clearly a database issue

[Kindred]

If you put the old database in -- then you have to change the data in the old database to point to the new location.  Paths, urls, etc are stored in two places.  The core information is in Settings.php -- the addiitonal (avatars, attachments, mod data, themes, etc) are stored in the database

As for repair_settings failing and you having to change it ---    that indicates an issue with your environment, since I have run repair_settings on at least 20 different servers and never had to make those changes.

[Dinky]

As for repair_settings failing and you having to change it ---    that indicates an issue with your environment, since I have run repair_settings on at least 20 different servers and never had to make those changes.

PHP 5.3.6 doesn't support square brackets being passed as function parameters - only array(). It's not a big issue. I assume that array() is still valid in later versions of PHP in which case the ultimate backwards compatibility would be to use array() instead of [].

Anyhow, back to your previous comment, I'm assuming those other settings are in the settings table? - Once i got the repair script changed and working it did pick up the old paths and updated them.. but the forum still crashes.

It's clearly some sort of database issue but i'll be damned if i can work out what and I used to be an advisor on the php forum of codingforums.com [nofollow] - so i'm no stranger to php debugging and fault finding but this ones got me stumped.

[Kindred]

Can you upgrade your php to at least 7?   And then try?

[Dinky]

I don't see that as a real solution. A fresh install works (once i hacked the installer to ignore the version of the database). Once installed, the fresh forum works fine.

This is a database woe.. and I've found it but I don't know how to fix it...

What i've done is backup both the original and fresh databases into different databases.. this then let me play Captain Debug..

One by one, I've copied the populated tables from the original forum database into the fresh database via phpmyadmin using the "drop if exists" feature. Then I refreshed the tab on the new forum after each successful copy.

The new forum worked well... until I copied smfpn_members into the fresh installs database. Not only did it exceed 30 odd seconds (odd considering there is only 17 members in it) but when i then refreshed the tab that is trying to visit the forum, the tab was unable to visit and went back to crashing - the apache error log showing the same old

*** UnKnown can't find 127.0.0.1: Not implemented

*** UnKnown can't find 127.0.0.1: Not implemented

[Tue Sep 26 21:28:48 2023] [notice] Parent: child process exited with status 3221225477 -- Restarting.

So for reasons unknown, it appears that mysql hangs on this table, exceeds some sort of timeout, php gives up and crashes out taking apache with it.

The question is why is this table knackered? - I've tried the repair option via phpmyadmin, i've tried  the flush option, optimising... it's as if the table causes mysql to use some sort of delay / hangs it.

[Kindred]

Well, 1- upgrading php is literally the thing that you will HAVE TO DO, soon....  5.3 is insecure for one.

2- please provide the exact structure of the bad table...
It would also help if you provided the data on the 17 rows (remove the email and password field contents)

[Dinky]

It gets murkier... so it starts with the members table... but copy the fresh members table back into place and the problem persists. Copy the entire fresh database back into place, it still persists. Put a fresh set of forum files (php images etc) back into place it still persists but a clean install works flawlessly (hacking out the version checking obviously which doesn't work properly).. but as soon as i try the live database again it all goes wrong - even if i then restore the fresh one and restart mysql.

It's all very odd. However it's looking like it might be a backwards compatibility woe - the server uses mariadb v10... i have mysql v5. It's looking like i'm going to need to transfer each row from each table via a base64 encoded http request instead - a trick i've used before. Yes it takes ages but it's powerful.

Well, 1- upgrading php is literally the thing that you will HAVE TO DO, soon....  5.3 is insecure for one.

No, it's not something I have to do. I can keep it running as long as I like. Insecure you say? I've only ever had one site hacked and it took them a year to get in. I only found out later it was a site that was attacked every month and had been for years (they omitted to tell me that). I kept them out for a year without any warning.

[Steve]

Sorry @Dinky but I have to agree with @Kindred (and not just because he's my boss). Just because you've been lucky so far doesn't mean you won't be in the future. As you say, you can do what you want but the advice of every single team member here is to upgrade it to the latest, most secure version.

[Kindred]

No, it's not something I have to do. I can keep it running as long as I like. Insecure you say? I've only ever had one site hacked and it took them a year to get in. I only found out later it was a site that was attacked every month and had been for years (they omitted to tell me that). I kept them out for a year without any warning.

Security through obscurity is no security at all.

Php 5.3 has known security holes in it. Period....   security holes in the system that runs your site - not the scripts,but the core itself.

Additionally,  smf modern versions require higher versions of php -- and the versions that run on the old php ALSO have issues which were patcheddar, but require modern php...

So, it's now a matter of when, not if, you will be hacked.

[Dinky]

The problem is that the VPS I am on has 5.3.6 installed - it's the last version before the compiler was changed and now you have to have all sorts of other dependencies so no more running from a usb drive or simnply firing it up...

Anyway... back to business..

I've installed mariadb 10.11.5.. tables imported ok (as per usual) forum still dead.

Installed it from clean with clean database - all good.

Copied my database into place: crashed (though just before that i did get on a page that said i'd exceeded my login attempts and to wait 30 seconds - then it crashed again).

Deleted my database and copied fresh database back into it: crash.

Restart apache & mariadb with fresh files and fresh DB in place: crash again.

I am stumped!

I have a clean installation of files - php, templates etc and it runs. They do not get changed by a database being copied over into place of a clean database. So i copy in my database and it then crashes -but surely no changes are made to any of the forum files? - Or are you storing php in the database and running it through exec? When i then delete that original database and copy a clean database back in, why on earth does it continue to crash?

I'm talking about the whole thing going down and restarting - php crashes and then takes apache with it which is restarted by the windows service controller.

[Kindred]

There is no php in the SMF database...

Did all the paths, etc remain the same?

[Dinky]

Yes - from the copied over version..

I've clearly got to go at this the old-skool way.. so I'm doing the infamous print __FILE__ .__LINE__;
exit; thing now...

On a fresh install, in index.php on line 115..

This has no effect - the forum still displays:

Code Select Expand

// Quickly catch random exceptions.
set_exception_handler(function ($e) use ($db_show_debug)
{print __FILE__ .__LINE__;
exit;

If I then swap the fresh database out and copy in my real one, using the exact same, it hangs and crashes.

However If I do this with the real database, it prints out and exits

Code Select Expand

print __FILE__ .__LINE__;
exit;
// Quickly catch random exceptions.
set_exception_handler(function ($e) use ($db_show_debug)
but it won't get past line 115. Both of the variables are null.

To recap, line 115 works on a fresh install / database but the moment i copy over the real database it won't get past that line. I was tempted to think that this was a php version glitch until i realised that it works with a fresh install.

[Dinky]

Well I realised that there are often some random files in /cache/ so I did a *.php and opened all the php files up in notepad. Copied over the real database and attempted a visit - hoping that notepad++ would detect a change in a file somewhere that might make sense.

Nothing. I am utterly stumped. I always get the best difficult problems to deal with and they usually take a few days.. but this one has really got me!

[Steve]

@Dinky - is this still an issue?