Migration issue - dev instance success vs live instance fail

Migration issue - dev instance success vs live instance fail

Jason Lane -
Erantzun kopurua: 5

Hello all, across this weekend we have migrated a cpanel account from an older server to a newer one. We are running an older Moodle 3.8 site in this cpanel account.

After migration I can see that the dev instance is working fine (in a 'beta' subdomain of the cpanel account) yet the live instance is not. I was able to login to the dev instance in admin mode, and it is now off maintenance mode and working as expected. The live instance is still not up and running. 

Live instance error:  "Service Unavailable. The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request."

What and where can I check to resolve please?

I noted the cpanel migration team changed some PHP settings from the old to the new server during the migration:
Old dev: ea-php72 > New dev: ea-php72 ** site is working **
Old live: alt-php70 > New live: ea-php74 ** 503 error **

And every 5 mins this is added to the error.log (assuming it's the cron?): 

 
[01-Apr-2025 19:10:01 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library 'intl.so' (tried: /opt/cpanel/ea-php74/root/usr/lib64/php/modules/intl.so (libicuuc.so.76: cannot open shared object file: No such file or directory), /opt/cpanel/ea-php74/root/usr/lib64/php/modules/intl.so.so (/opt/cpanel/ea-php74/root/usr/lib64/php/modules/intl.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0


Thank you for your assistance, Jason

Puntuazioen batez bestekoa: -
Jason Lane(e)ri erantzunda

Migration issue - dev instance success vs live instance fail

Jason Lane -
Quick update to my message - the error.log is not adding more entries, so maybe that's resolved and there is another cause.

The last 3 error log records were at:
[01-Apr-2025 19:00:01 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'intl.so' ...
[01-Apr-2025 19:05:01 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'intl.so' ...
[01-Apr-2025 19:10:01 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'intl.so' ...
Jason Lane(e)ri erantzunda

Migration issue - dev instance success vs live instance fail

Ken Task -
Particularly helpful Moodlers-ren irudia

What is point number of your 3.8? ... the last digit ... 3.8.X ... the X.

Please see:

https://moodledev.io/general/releases/3.8
Server requirements
PHP version: minimum PHP 7.1.0 Note: minimum PHP version has increased since Moodle 3.6. PHP 7.2.x, 7.3.x and 7.4.x (since Moodle 3.8.3) are supported too. See Moodle and PHP for details.
PHP extension intl is required since Moodle 3.4 (it was recommended in 2.0 onwards)

The error about intl.so shows your cpanel/easy apache php is looking for an intl.so.so file.  See the double extension?  Dunno what's up with that!  intl.so file evidently exist as your other site works.

CPanel Easy Apache has a setting for default (all sites/domains) but it  can set php version AND extensions per domain site.  Is the broken site set to load php's php-intl extension?   Compare the two ... replicate the one working.

'SoS', Ken

Puntuazioen batez bestekoa:Useful (1)
Ken Task(e)ri erantzunda

Migration issue - dev instance success vs live instance fail

Jason Lane -
Thank you Ken. Our version is Moodle 3.8.4+ (Build: 20200903)

I still have no idea why the live site is broken.

The migration team said this during the migration process: "We have resolved the post-migration issue, which was caused by a mismatch between CloudLinux alt-php and ea-php along with the PHP handler configuration. This issue was not related to the redirection rules."

I have since deleted the redirection rule (301 redirect to /learn) and tried to load even the index of the broken site and there is still a 503 error. Even trying

Interestingly, the migration people sent a screenshot of the live site working - but ever since then all I get is persistent 503 errors.

Is there anything else I can do please?
Jason Lane(e)ri erantzunda

Migration issue - dev instance success vs live instance fail

Ken Task -
Particularly helpful Moodlers-ren irudia

'anything else you can do' ... yeah, lots of things, but would those be the right things?

Comment: it doesn't take a 'team' to migrate a moodle! :|

Previously you reported the error that indicated a 'capacity' issue.
Hope you've not leased a package that simply doesn't have to the resources to run 2 moodle instances.

Got command line?

Issue:

free -h

This:
mismatch between CloudLinux alt-php and ea-php along with the PHP handler configuration

ea-php is a cPanel tool .. alt-php is a command line tool (I think).


So you have a dev site with a FQDN of its own and it's working.
Your production moodle is in /learn ... not at document root for its domain. Is there an .htaccess file at document root of the production site? What does it contain?

Might want to do the following from command line:

cd /path/to/productionsystem/directory/ - which is /learn?
php -v
You should see php-cli and a version.   What is that version?

Have you purged caches?
Can do that via command line:
cd /path/to/productionsystem/admin/cli/
php purge_caches.php

Might want to also clear your browser cache.

Sent you a PM ... please respond there!

'SoS', Ken

Puntuazioen batez bestekoa:Useful (1)
Jason Lane(e)ri erantzunda

Migration issue - dev instance success vs live instance fail

Ken Task -
Particularly helpful Moodlers-ren irudia

And some more ...

And another thought ... when migrating, one usually does NOT migrate a old cPanel to a new environment.   One migrates only a site backup of moodle.

From command line an in production moodle code location, issue:
ps aux |grep php
The 'darling' setup now for more modern OS's is php-fpm.
The 503 error is a gateway error and could be coming from a php-fpm setup that needs tweaking upwards.  php-fpm does use a gateway.

What you should see is something like:
root        1114  0.0  0.1 470460 37004 ?        Ss   Mar28   0:26 php-fpm: master process (/etc/opt/remi/php82/php-fpm.conf)
apache      1674  0.0  0.5 549400 166516 ?       S    Mar28   4:03 php-fpm: pool www
apache      1675  0.0  0.5 549928 163288 ?       S    Mar28   4:06 php-fpm: pool www
apache      1676  0.0  0.5 549456 166660 ?       S    Mar28   4:07 php-fpm: pool www
apache      1677  0.0  0.5 494160 183624 ?       S    Mar28   4:08 php-fpm: pool www
apache      1680  0.0  0.5 549744 163020 ?       S    Mar28   4:03 php-fpm: pool www
apache     12502  0.0  0.4 475836 153856 ?       S    Mar28   4:13 php-fpm: pool www
apache     12749  0.0  0.4 549468 162044 ?       S    Mar28   4:13 php-fpm: pool www
apache    116759  0.0  0.4 477832 154220 ?       S    Mar28   4:00 php-fpm: pool www
apache    453553  0.0  0.5 555504 170928 ?       S    Mar29   3:26 php-fpm: pool www
apache    633036  0.0  0.4 549820 160352 ?       S    Mar30   2:55 php-fpm: pool www

your path to the master php-fpm.conf file would be different.
cd your path and then ls
You should see something like:
opt  php.d  php-fpm.conf  php-fpm.d  php.ini  pki  pm  skel  sysconfig  X11  xdg  xinetd.d

At the bottom of php-fpm.conf, you might need to add php tweaks upwards. Example from one of my severs:

php_admin_value[max_input_vars] = 6000
php_admin_value[memory_limit] = 256Mphp 
php_admin_value[post_max_size] = 256M
php_admin_value[upload_max_filesize] = 256M
php_admin_value[max_execution_time] = 90
php_admin_value[max_input_time] = 120

You probably do not have those in yours.

Also, there is a conf file for php-fpm pool which points to a www.conf file. That's another area of php tweaks you need to investigate.
If you do make tweaks, the php-fpm process needs to be restarted.

systemctl reload php-fpm
systemctl status php-fpm

You can test the setup:
/opt/remi/php82/root/usr/sbin/php-fpm -tt
your path to php-fpm would be different than in above example.

And, you've a 'moodle march' ahead ... 3.8 is very very old and to 'march' the moodle upwards will require changing PHP version the domain runs under just before an update of moodle code to a higher version.  Suggest, when you do regain access to the admin side of that moodle, going to Server -> Environment check and update the component.

And consulting the moodle releases site for versions higher than 3.8 to see what is required during the march.

One last ... by far the best way to update/maintain a moodle is using git versioning.   Might be well worth your time to get your current 3.8 under git versioning first - which would result in an upgrade to the highest 3.8 available.

https://docs.moodle.org/501/en/Git_for_Administrators

Not sure I'd take the sites all the way to 5.1 ... might stop at 4.5.highest for now.   5.1 involves a restructuring of moodle code/files that's 'different'.   And you might want to practice that on your DEV system first ... that's why it's important to be able to control php version and setup per domains on your server.

My more than 2 cents.

'SoS', Ken

Puntuazioen batez bestekoa:Useful (1)