Search results: 568
I have not done that (setting up cron jobs) before either - so any advice on this area is also very welcome
Got some info re server below from WHM: (most gobbledygook to me but maybe you can spot something I should tweak or upgrade, prettu sure my server should be OK to handle the load, I don't know how big the actual site is, however...... current provided not really telling me squat apart from - you will get the backups of DT and moodledata monday and then bye bye.
My server is CentOS Linux release 7.9.2009 (Core)
Server Version: Apache/2.4.48 (cPanel) OpenSSL/1.1.1k mod_bwlimited/1.4
Server MPM: prefork
Server Built: Jun 30 2021 17:18:56
Server load: 0.10 0.23 0.20
Total accesses: 1439227 - Total Traffic: 59.2 GB - Total Duration: 850858328
CPU Usage: u9.56 s56.52 cu1929.32 cs1305.77 - .187% CPU load
Server Load 0.138672 (8 CPUs)
Memory Used 26.63% (4,285,544 of 16,094,416)
Swap Used 0.02% (1,012 of 4,194,300)
Total processors: 8
Name Intel(R) Xeon(R) CPU E3-1230 v6 @ 3.50GHz
Speed 3500.000 MHz
Cache 8192 KB
[ 0.000000] Memory: 4016380k/18612224k available (6916k kernel code, 2008532k absent, 530716k reserved, 4551k data, 1800k init)
Linux 22.214.171.124.srvlist.ukfast.net 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 01:06:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[ 2.369081] sd 0:2:0:0: [sda] 233308160 512-byte logical blocks: (119 GB/111 GiB)
[ 2.369733] sd 0:2:0:0: [sda] Write Protect is off
[ 2.370044] sd 0:2:0:0: [sda] Mode Sense: 1f 00 10 08
[ 2.370062] sd 0:2:0:0: [sda] Write cache: disabled, read cache: disabled, supports DPO and FUA
[ 2.371909] sda: sda1 sda2
[ 2.372469] sd 0:2:0:0: [sda] Attached SCSI disk
[ 3.250723] sd 0:2:0:0: Attached scsi generic sg0 type 0
Current Memory Usage:
total used free shared buff/cache available
Mem: 16094416 2777764 2457980 133760 10858672 12841492
Swap: 4194300 1012 4193288
Total: 20288716 2778776 6651268
Current Disk Usage:
Filesystem Size Used Avail Use% Mounted on
devtmpfs 7.7G 0 7.7G 0% /dev
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 7.7G 1.1M 7.7G 1% /run
tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup
/dev/mapper/vg_main-lv_root 104G 41G 58G 42% /
/dev/sda1 976M 144M 766M 16% /boot
tmpfs 1.6G 0 1.6G 0% /run/user/0
So, a couple of things I would recommend to you:
1. allow the cron job for all of your moodles to be executed from the web. (you have to be logged on as an admin user and provide a password for the url to the cron script).
2. I have uploaded an sos.html page at the root of thrives. Login as the admin level user and after logging on as admin user, use same browser to go to https://yourthrivesite/sos.html
The page has relative links to the following admin areas which you've reported don't show once you've logged on. These links should work. Kinda cumbersome navigating to this sos.html page all the time to get admin stuff done, but you might be able to limp along with thrive until you migrate to
a more robust system (for others, OP has said plans to migrate to another hosting service that's more robust - OP - see link about migrating below).
Purge All Caches
Yes, the site is on shared hosting, but I can't get access to a cPanel unfortunately, as I'm only supposed to "manage it" and don't have access to the server configuration, contractual data, and so on, sigh!
I don't think it's an overload of the database, because of the following leads:
- without a working cron, the site was able to handle the traffic just fine and yesterday nobody except me was online
- it's always this one query, that results in an error: SELECT * FROM mdl_context WHERE contextlevel = ?
0 => 10,
I think the database contents is somehow corrupted – probably because of cron not running for so long. Is there a "repair everything" function may?
Pardon intrusion ... @Nicholas ... you might want to share more info about 'a webhosting service'. Is site on shared hosting? Do you have access to a 'cPanel'? (that does show brief info about a shared DB server). If using a shared hosted DB server with site, that can be seen in config.php of the code of moodle.
On shared hosting, an admin person is greatly limited as to what one can do.
Site may have grown beyond the limits of shared hosting.
Then, you need to identify the path to your PHP file. It might be something like .../ea-php73/... and make this change to your cron job. Your Moodle 3.7 should work fine with php73.
Before answering and providing links for how 2's in Moodle docs, please expand upon this:
especially the 'same domain' part ... do you mean same top level domain or another fresh 3.11 in a sub domain of the top level domain? ... like m311.smartlearn.education.
Easy Apache is outside of Moodle ... via cPanel ... it can set the version of PHP to run per domain ... top level or subdomain as your screen shot shows.
Yes, any higher version of moodle installed it would be advised to add another cron job that points to the version of PHP a Moodle is running under.
Moodle 3.11 under PHP 7.3 then the path to the php-cli to execute the code/admin/cli/cron.php script should point to the Easy Apache 7.3.
Any reason not to just upgrade the 3.7? That would require hops as one cannot upgrade to 3.11.highest straight from 3.7.highest. Is that what we are trying to avoid?
|I have production moodle 3.7
now i want to install a clean 3.11 on the same server and same domain ( different folder, data folder ,database )
3.11 need php 7.3
my 3.7 run on php 7.2
and cron job as:
/opt/cpanel/ea-php72/root/usr/bin/php -q /home/mnabil/public_html/admin/cli/cron.php "
can i upgrade php via this button ?
is it revirsible ?
do i change my cron jop string for my moodle 3.7?
Actually we are not using CloudFlare
On staging server are you allowing the running of cron via the web? - No
Since we see cPanel is involved, is cPanel code up to date? - Yes
Upgrading your moodle might not be too hard. I am not sure if you have been installing a lot of plugins, which could complicate the upgrade. I made some videos that might help, but I made these using cPanel, not Plesk.