We are having cron problems after upgrading to Moodle 4.2 from Moodle 4.1
Moodle says:
The admin/cli/cron.php script has not been run for 3 days 3 hours and should run every 1 min.
cron email says:
!!! Exception - syntax error, unexpected ')', expecting variable (T_VARIABLE) !!!
(To make sure it wasn't a security problem, I checked cron.php and it was 664.)
I tried submitting a ticket in Tracker (jira), but it says I failed to demonstrate that I searched existing tickets. But I did! I don't know what kind of proof they want.
Any insights? Thanks!
-- Russ Schwartz
Did you run the Server Environment check prior to the upgrade?
Did you check release notes for 4.1?
Error suggest incompat php version ... which also includes php-cli that is used to run the admin/cli/cron.php script.
'SoS', Ken
Thanks for the quick reply, Ken!
The Moodle Server Check says:
version 8.0.0 is required and you are running 8.0.28
I checked my service provider and they, too, said I was running php 8.0
I'll check the documentation further per your recommendation ...
-- Russ
The Moodle Server Check says:
version 8.0.0 is required and you are running 8.0.28
I checked my service provider and they, too, said I was running php 8.0
I'll check the documentation further per your recommendation ...
-- Russ
Cron job is setup outside of Moodle but should point to /path/to/moodlecode/admin/cli/cron.php. It's the first part of the setup of cron you need to check ... /path/to/php which should be pointed to the 8.0 php-cli.
Got terminal/ssh into server? If so ...
cd path/to/moodlecode/
which php
That last command will show which cli php your system is finding via cli - a path.
Use that path in the following command:
/pathseeninwhich/php -v
Does that show version 8.0 of php-cli?
If not, then you need to check for multi-php setup on your server and find the path to version 8.0 of your PHP. Can't tell you what that would be.
'SoS', Ken
Thanks, for more clues, Ken! Let's see what I can find out ...
-- Russ
-- Russ
Ah-HA! The plot thickens!
When I issued those commands that Ken Task suggested, I saw:
When I issued those commands that Ken Task suggested, I saw:
PHP 7.4.30 (cli) (built: Sep 13 2022 05:22:55) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.30, Copyright (c), by Zend Technologies
BUT: The Moodle Server Check says:
version 8.0.0 is required and you are running 8.0.28
So now I have a ticket in back at my Web Host saying, "Okay, which version am I really running?" (In an earlier message, where I asked them if I was running 64-bit 8.0, they said yes. Hmmm....)
AND: My Web Host says:
This domain is using PHP 8.0 FastCGI
Actually, the plot 'sickens' ... in that help desk couldn't help you with a cron job! 
You might mention where (ok to name provider) and how you are hosted (high end shared hosted package or a VPS) for others who might run across the same issue.
fastcgi has nothing to do with setup of a simple cron job pointed at a php script from command line. So am not totally dis-crediting nor making you trust help desk less, most tech support folks don't know much about Moodle cause it's a beast to itself!
Your server has the ability to run different versions of PHP per domain.
So do you have a web based tool to setup cron jobs? like cPanel/Plesk/other?
Access that tool and see what the path to the first part - the php - is.
Might be something like: /usr/bin/php /path/to/moodlecode/admin/cli/cron.php
Is that path the same path you saw when issuing the commands I have you?
Do this to see if that is an alias:
ls -l /path/to/php seen in output of which.
Now we need to find out where php-cli is for your version 8.
and change the default path - which points to the older 7.4 - to the desired version 8.
'SoS', Ken
Follow up ... didn't suggest how to find the php-cli for version 8 ...
Servers that have multiple versions of PHP available, usually store those in /opt/ directory.
Commands:
cd /opt/
find ./ -name php
The find command will find a bunch and you are looking for something that indicates version 8.
Once you see the path to version 8, see where php-cli is ...
Output might be something like: /opt/php/vr8/bin/php
To see if that is php-cli:
/opt/php/vr8/bin/php -v
IF you see php-cli in output of the version command, that's your path you use in your setup of cron job.
Also, in moodlecode/ there is a paths area ... set the path to php-cli to that same path.
Fingers crossed ... we'll get this worked out!
'SoS', Ken
Ken,
Re: Plot "sickens..." LOL!
Interesting, my provider told me that the PHP that Moodle runs and the PHP the ssh sees (which I determined using the commands you gave me) are two different things. Who knew?
I define my cron job on my provider's server with an unnamed tools. I type in a command, click some pull-downs about when to run it, press a button, and that's it.
Here's the command:
/usr/bin/php /home/licc_admin/liberiainternationalcc.org/moodle/admin/cli/cron.php
I got that out of the 4.1 release notes when I installed Moodle. Now I need to check the 4.2 release notes to see if anything changed.
Also, I want to do some/all of the stuff you mentioned in your 2 most recent messages. What should keep me busy for a while!
Thanks again for the help. It's shown me what questions to ask my provider, how to interpret their answers that are sometimes beyond my competence, and to check things myself before I ask questions so I can pretend to know what's going on. ;)
-- Russ
Re: Plot "sickens..." LOL!
Interesting, my provider told me that the PHP that Moodle runs and the PHP the ssh sees (which I determined using the commands you gave me) are two different things. Who knew?
I define my cron job on my provider's server with an unnamed tools. I type in a command, click some pull-downs about when to run it, press a button, and that's it.
Here's the command:
/usr/bin/php /home/licc_admin/liberiainternationalcc.org/moodle/admin/cli/cron.php
I got that out of the 4.1 release notes when I installed Moodle. Now I need to check the 4.2 release notes to see if anything changed.
Also, I want to do some/all of the stuff you mentioned in your 2 most recent messages. What should keep me busy for a while!
Thanks again for the help. It's shown me what questions to ask my provider, how to interpret their answers that are sometimes beyond my competence, and to check things myself before I ask questions so I can pretend to know what's going on. ;)
-- Russ
I tried to follow Ken's procedure, and here were the results:
[daniel-carroll]$ ls -l /usr/bin/php
lrwxrwxrwx 1 root root 21 Feb 2 2020 /usr/bin/php -> /etc/alternatives/php
[daniel-carroll]$ cd /opt/
[daniel-carroll]$ find ./ -name php
find: './plow': Permission denied
Then I had a brainstorm: Why not try to see what cron sees?
So first I created a cron job that issued the command: which php
The output was: /usr/bin/php
So I modified the job to give the command: /usr/bin/php -v
and the output was:
PHP 7.4.30 (cli) (built: Sep 13 2022 05:22:55) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.30, Copyright (c), by Zend Technologies
That would explain the error.
But why does Moodle tell me that it's running 8.0.28 ?
And why does my provider insist that my Moodle site is running 8.0 ?
No matter. My provider sent me an article entitled "Change the PHP version the shell uses"
So I will try that next.
As Paul Harvey used to say, "Stand by for news!"
[daniel-carroll]$ ls -l /usr/bin/php
lrwxrwxrwx 1 root root 21 Feb 2 2020 /usr/bin/php -> /etc/alternatives/php
[daniel-carroll]$ cd /opt/
[daniel-carroll]$ find ./ -name php
find: './plow': Permission denied
Then I had a brainstorm: Why not try to see what cron sees?
So first I created a cron job that issued the command: which php
The output was: /usr/bin/php
So I modified the job to give the command: /usr/bin/php -v
and the output was:
PHP 7.4.30 (cli) (built: Sep 13 2022 05:22:55) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.30, Copyright (c), by Zend Technologies
That would explain the error.
But why does Moodle tell me that it's running 8.0.28 ?
And why does my provider insist that my Moodle site is running 8.0 ?
No matter. My provider sent me an article entitled "Change the PHP version the shell uses"
So I will try that next.
As Paul Harvey used to say, "Stand by for news!"
PS,
They told me to add this line to my .bash_profile file:
export PATH=/usr/local/php82/bin:$PATH
and then execute this command:
. ~/.bash_profile
And, at least when I do a "php -v" from within ssh, 8.2 is what's now running.
So now the big wait is to see what happens when the cron job runs and finishes.
(I should mention that the server / php info report still thinks Moodle is running 8.0.28)
If this doesn't work, then I'll ask my provider to just out-and-out change me so I'm running 8.1 or better anywhere -- in ssh, in cron, whatever.
They told me to add this line to my .bash_profile file:
export PATH=/usr/local/php82/bin:$PATH
and then execute this command:
. ~/.bash_profile
And, at least when I do a "php -v" from within ssh, 8.2 is what's now running.
So now the big wait is to see what happens when the cron job runs and finishes.
(I should mention that the server / php info report still thinks Moodle is running 8.0.28)
If this doesn't work, then I'll ask my provider to just out-and-out change me so I'm running 8.1 or better anywhere -- in ssh, in cron, whatever.
You have 2 php executables ... 1 is used for command line (in this case we are trying to setup a cron job for moodle) ... the other is used with your web services (apache/fastcgi or other).
They got close:
When at the command line your shell is controlled by the environment.
Just to get an idea of how complicated that is, issue: env [ENTER] and see.
You need 8.0 - not 8.2
So this line:
export PATH=/usr/local/php82/bin:$PATH
in your .bash_profile file
needs to change to:
export PATH=/usr/local/php80/bin:$PATH
See the difference?
log out of the shell, then log back in again - env is read/setup when you first login.
Then issue: php -v
You should see it return version 8.0.23 php-cli
and now you can setup your cron job using:
/usr/bin/php /path/to/moodlecode/admin/cli/cron.php
/usr/bin/php is a symlink (alias in Mac OS, shortcut in Windoze)
When you issued:
ls -l /usr/bin/php it showed a -> pointer to the real php executable.
That clear as mud? 
'SoS
I just edited the .bash_profile file as specified.
And when I connect to the server using ssh and do a php -v I am running 8.0.23 as noted.
But Moodle still thinks it is running a different PHP version. (It's 8.1.17 since I upgraded the web site.)
And the cron is still failing.
I'm getting confused. It looks like there is one PHP that runs under ssh, another version that runs under cron, and a third version that runs when I just go to Moodle in my browser.
I have a ticket in to my provider saying, "Please make everything run under one version."
I'm definitely "in over my head" here....
And when I connect to the server using ssh and do a php -v I am running 8.0.23 as noted.
But Moodle still thinks it is running a different PHP version. (It's 8.1.17 since I upgraded the web site.)
And the cron is still failing.
I'm getting confused. It looks like there is one PHP that runs under ssh, another version that runs under cron, and a third version that runs when I just go to Moodle in my browser.
I have a ticket in to my provider saying, "Please make everything run under one version."
I'm definitely "in over my head" here....
Follow up ... when they had you edit your .bash_profile that's for your account. So when you login and issue php -v that path is in *your* environment.
While you have access to some tool to set up the cron job, under what user does the cron job run? Recommended to be the user your web service runs under.
And you might not be out of the woods yet ... if that symlink is still pointed as you shared ... it looks incorrect to me - not the same as the path in environment.
It just keeps getting deeper and deeper, huh? Sorry 'bout that ... nature of the beast.
'SoS', Ken
Ken,
I have no idea what user the cron job runs under. The messages I get from cron have subject lines like this:
Cron <admin_acct_name@server_name> /usr/local/bin/setlock -n /tmp/cronlock.2901942.250631 sh -c '/usr/bin/php /home/admin_acct_name/web_site_name/moodle/admin/cli/cron.php'
where admin_acct_name and web_site_name are disguises in this message for the real names.
I assume the cron job is running under admin_acct_name, but I don't know that.
Now we'll see what my service provider says/does....
I have no idea what user the cron job runs under. The messages I get from cron have subject lines like this:
Cron <admin_acct_name@server_name> /usr/local/bin/setlock -n /tmp/cronlock.2901942.250631 sh -c '/usr/bin/php /home/admin_acct_name/web_site_name/moodle/admin/cli/cron.php'
where admin_acct_name and web_site_name are disguises in this message for the real names.
I assume the cron job is running under admin_acct_name, but I don't know that.
Now we'll see what my service provider says/does....
Your site is hosted on DreamHost
Several articles on cron jobs
A few on Moodle
https://help.dreamhost.com/hc/en-us/search?utf8=%E2%9C%93&query=moodle&commit=Search
And Moodle has official docs on Cron
They do have a Knowledge Base
https://help.dreamhost.com/hc/en-us/search?utf8=%E2%9C%93&query=cron+job&commit=SearchSeveral articles on cron jobs
A few on Moodle
https://help.dreamhost.com/hc/en-us/search?utf8=%E2%9C%93&query=moodle&commit=Search
And Moodle has official docs on Cron
Your job, as admin of the moodle, is to put those bits of info together where the cron job works. Sounds easy enough and once you do get it setup 'light bulbs' will come on and sometimes you look back and think, I should have been able to figure that out! Uhhhh ... lt's called learning!
Understand that you are just learning and that this moodle site is really a 'proof of concept' to see if your entity can use it or not ... you think they can ... remains to be seen/known by the persons actually making the decisions.
One thing that should be learned by now is that a person with some understanding of how to run a web site (moodle in particular) is needed.
It's a journey ... confusing af first ... but it eventually gets better with more experience. Until then you have 3 resources for problems/issues.
First your hosting providers Knowledge Base (KB)
Second your help desk folks
Third these free forums.
Probably in that order. Not that am dodging here ... when you talk to your help desk looking at hosting providers KB first might give you info to frame your questions or request for assistance clearer.
Your hosting provider doesn't specialize in hosting moodle's and thus a help desk person who doesn't have experience at admin of a moodle might provide solution that's in-complete ... but will eventually get sorted ... think that's kinda where we are at now.
And as you already know, it's not good to share too much information here in public forums ... am a 'white hat' ... but 'black hats' (those that would do harm) have access to these discussions as well.
Hang in there ... you are close!
But do understand this .. moodle is not and never has been an 'install it once and forget it'. It has always be an application that requires care and maintenance (updates and upgrades at times).
Do learn how to backup your moodle site cause once you have gone through the pain of this upgrade you do want assurance that you have one.
'SoS', Ken
MoodleCloud has a free trial period of 45 days.
Hi, Ken!
Re: Use of knowledge base. I agree completely. When I worked at Digital Equipment Corporation back in the 80s, we had the EasyNet, which was very much like the Internet except that the Application Layer was different. Conversations like you and I are now having were in an app called VAXNotes. Each product also had its own VAXNotes app, which was its knowledge base. When we would call the help desk in Colorado Springs, their Question #1 was always, "Did you read the Notes files?
I have to thank you for your patience with me. Elsewhere, I posted that I am on assignment in a country that is much hotter and more humid than my own. I have made a variety of poor choices (such as installing a non-LTS Moodle, and doing so the day it was announced) do to my brain not working right. Mea Culpa! I must plead temporary insanity! ;)
I shall (1) read the recommended articles, (2) see if I can go back to PHP 8.0 through my site manager, and (3) per DreamHost, modify .bash_profile to use the "alias" command instead of the other one.
-- Russ
Re: Use of knowledge base. I agree completely. When I worked at Digital Equipment Corporation back in the 80s, we had the EasyNet, which was very much like the Internet except that the Application Layer was different. Conversations like you and I are now having were in an app called VAXNotes. Each product also had its own VAXNotes app, which was its knowledge base. When we would call the help desk in Colorado Springs, their Question #1 was always, "Did you read the Notes files?
I have to thank you for your patience with me. Elsewhere, I posted that I am on assignment in a country that is much hotter and more humid than my own. I have made a variety of poor choices (such as installing a non-LTS Moodle, and doing so the day it was announced) do to my brain not working right. Mea Culpa! I must plead temporary insanity! ;)
I shall (1) read the recommended articles, (2) see if I can go back to PHP 8.0 through my site manager, and (3) per DreamHost, modify .bash_profile to use the "alias" command instead of the other one.
-- Russ
To others following this thread:
Please note that that the problem I have been experiencing here is "normal and expected" for almost any application.
A developer can build all kinds of rules into application software and triggers and constraints into databases to protect users from themselves. But system management is always risky territory. Some tasks, not done right, can be disruptive or destructive. (Moodle gives advice on this when you set certain system parameters.)
For this reason, I almost always log in using a Teacher role. I only log in as Administrator when I need a higher-than-normal privilege to do something.
I beg you not to conclude from this conversation that Moodle is "buggy" or otherwise lacking in quality. The problems I am having are my own fault, not those of the Moodle developers or quality unit. My opinion of Moodle has not diminished in any way.
I am still a #1 Moodle Fan! <3 <3 <3
Please note that that the problem I have been experiencing here is "normal and expected" for almost any application.
A developer can build all kinds of rules into application software and triggers and constraints into databases to protect users from themselves. But system management is always risky territory. Some tasks, not done right, can be disruptive or destructive. (Moodle gives advice on this when you set certain system parameters.)
For this reason, I almost always log in using a Teacher role. I only log in as Administrator when I need a higher-than-normal privilege to do something.
I beg you not to conclude from this conversation that Moodle is "buggy" or otherwise lacking in quality. The problems I am having are my own fault, not those of the Moodle developers or quality unit. My opinion of Moodle has not diminished in any way.
I am still a #1 Moodle Fan! <3 <3 <3
In reply to Russell Schwartz
Moodle for hotter and more humid countries ;-) [OT]
by Visvanath Ratnaweera -
You hotter and more humid country reminded me of the discussion Chatterbox: Mobile Moodle micro-servers in rural Zimbabwe.
In reply to Visvanath Ratnaweera
Re: Moodle for hotter and more humid countries ;-) [OT]
by Russell Schwartz -
Indeed, Visvanath, we had reachable solar panels stolen as well. Rather than lock them up at night we just put them up too high. ;) BTW, I am in Liberia.
-- Russ
-- Russ
I am still going through the knowledge base articles and double-checking things.
Here is where I am now:
I have put the web site back to PHP 8.0 FastCGI as required by Moodle 4.2
Here is where I am now:
I have put the web site back to PHP 8.0 FastCGI as required by Moodle 4.2
I have the following line in .bash_profile as recommended by DreamHost:
alias php='/usr/local/php80/bin/php'
The cron job is still giving me this error:
!!! Exception - syntax error, unexpected ')', expecting variable (T_VARIABLE) !!!
I enabled the deprecated web-based cron command with password required (to thwart the "black hats" as Ken mentioned). I ran it and it completed successfully.
It seems like I am set up about 98% right. There must be some small thing that is escaping DreamHost or me. Perhaps it has something to do with what Visavanath about "running as the owner of the web process". I doubt I have server privileges to run jobs under any other user id than my own, but I'll check around ...
-- Russ
alias php='/usr/local/php80/bin/php'
The cron job is still giving me this error:
!!! Exception - syntax error, unexpected ')', expecting variable (T_VARIABLE) !!!
I enabled the deprecated web-based cron command with password required (to thwart the "black hats" as Ken mentioned). I ran it and it completed successfully.
It seems like I am set up about 98% right. There must be some small thing that is escaping DreamHost or me. Perhaps it has something to do with what Visavanath about "running as the owner of the web process". I doubt I have server privileges to run jobs under any other user id than my own, but I'll check around ...
-- Russ
Hi Russel
You wrote:
> put the web site back to PHP 8.0 FastCGI as required by Moodle 4.2
PHP 8.0 is the key. It could be FastCGI or PHP-FPM. May be other models too. Or do you have a quote which says otherwise?
> I doubt I have server privileges to run jobs under any other user id than my own,
If you are the true 'root', you can:
You wrote:
> put the web site back to PHP 8.0 FastCGI as required by Moodle 4.2
PHP 8.0 is the key. It could be FastCGI or PHP-FPM. May be other models too. Or do you have a quote which says otherwise?
> I doubt I have server privileges to run jobs under any other user id than my own,
If you are the true 'root', you can:
# crontab -u TARGET-USER -e
Per your suggestion, I tried to create the cron job using crontab. The editor will not allow me to write the edited file.
I shall pass this on to DreamHost and see if somebody with privileges will use crontab to force the "-u"
-- Russ
I shall pass this on to DreamHost and see if somebody with privileges will use crontab to force the "-u"
-- Russ
DreamHost says:
Regarding the error message you are seeing, "!!! Exception - syntax
error, unexpected ')', expecting variable (T_VARIABLE) !!!", this
typically indicates that there is a syntax error in the code that is
being executed by the cron job. The error message specifically suggests
that the code is encountering an unexpected closing parenthesis ")" where
a variable should be expected.
Has this issue devolved to finger-pointing? I'm surprised. It's not like DreamHost to do that ...
Regarding the error message you are seeing, "!!! Exception - syntax
error, unexpected ')', expecting variable (T_VARIABLE) !!!", this
typically indicates that there is a syntax error in the code that is
being executed by the cron job. The error message specifically suggests
that the code is encountering an unexpected closing parenthesis ")" where
a variable should be expected.
Has this issue devolved to finger-pointing? I'm surprised. It's not like DreamHost to do that ...
Poor DreamHost.
Question: Why does a program throw a syntax error during compilation?
DH: Because the program code has a coding error.
What DH overlooked: The programming language has changed! The new compiler doesn't like the old code!
Question: Why does a program throw a syntax error during compilation?
DH: Because the program code has a coding error.
What DH overlooked: The programming language has changed! The new compiler doesn't like the old code!
Visvanath, you wrote:
PHP 8.0 is the key. It could be FastCGI or PHP-FPM. May be other models too. Or do you have a quote which says otherwise?
I have 2 choices: (a) FastCGI 8.0 or (b) CGI 8.0.
Currently, my site is set up for FastCGI 8.0. As soon as i get through the current dialogue with DreamHost, I shall switch to "regular" CGI 8.0 and see what happens.
-- Russ
PHP 8.0 is the key. It could be FastCGI or PHP-FPM. May be other models too. Or do you have a quote which says otherwise?
I have 2 choices: (a) FastCGI 8.0 or (b) CGI 8.0.
Currently, my site is set up for FastCGI 8.0. As soon as i get through the current dialogue with DreamHost, I shall switch to "regular" CGI 8.0 and see what happens.
-- Russ
You misunderstood. Your phrase "put the web site back to PHP 8.0 FastCGI as required by Moodle 4.2" implies that Moodle 4.2 _requires_ PHP FastCGI, which is not the case. If you have FastCGI set up, why change?
Visvanath,
I mis-spoke. Originally I had PHP 8.0 FastCGI. I changed to PHP 8.1 FastCGI. When I learned that Moodle 4.2 wants 8.0, I changed back to PHP 8.0 FastCGI because that's what I had before. By "required" I only meant 8.0, but my grammar implied 8.0 FastCGI. Sorry to mislead....
Before I try CGI 8.0, I will leave it at FastCGI 8.0. DreamHost told me I could work around my crontab privilege problems by showing me a KB article on how to create my own crontab file that takes precedence over the server's file.
I'm going to try that and see what happens....
I mis-spoke. Originally I had PHP 8.0 FastCGI. I changed to PHP 8.1 FastCGI. When I learned that Moodle 4.2 wants 8.0, I changed back to PHP 8.0 FastCGI because that's what I had before. By "required" I only meant 8.0, but my grammar implied 8.0 FastCGI. Sorry to mislead....
Before I try CGI 8.0, I will leave it at FastCGI 8.0. DreamHost told me I could work around my crontab privilege problems by showing me a KB article on how to create my own crontab file that takes precedence over the server's file.
I'm going to try that and see what happens....
Does your provider have a panel (cPanel by name) for customers to use? If they do, use that to set up the cron job.
I'll answer that for you: no DreamHost does not offer cPanel, but does offer one of their own:
And since their KB is public, what's the url to the KB article they shared with you?
This one?
Here's another DreamHost specific KB article that you need to read:
'SoS', Ken
Ken: >> > Does your provider have a panel (cPanel by name) for customers to use? If they do, use that to set up the cron job. >>> I'll answer that for you: no DreamHost does not offer cPanel, but does offer one of their own: Yes, I was using that one until this morning. Then I deleted it. >>> And since their KB is public, what's the url to the KB article they shared with you? >>> This one? DreamHost sent me this same article, so I created a new cron job this way. It does not appear to be running ... at all. I am not getting any emails back from the job. Now I have a ticket in on that one. >>> Here's another DreamHost specific KB article that you need to read: That one is informative, although I'm not sure what action I should take as a result. I'm about ready to punt. If they can't tell me why my newest cron job -- which they told me to create -- and which I created following their instructions -- does not run, then I'm done. I think Visvanath's earlier "Poor DreamHost" comment pretty much sums up the situation. I have enabled the web execution of cron.php (with password!) and I will just run it 2-3 times a day until the semester is over. Then I'll back up everything, delete all the files, and reinstall Moodle 4.1. Thanks for the help. I think we got very close. -- Russ |
First, the web based cron job ability has been slated for 'depreciation' ... meaning it will be removed from Moodle. They didn't say when.
'deleted panel' - have never seen a provider that would allow that! No offense - think that was a mistake cause now you have a command line only server.
The KB article on setting up a cron job had several examples ... which one did you do? Ok to share that here.
The KB article on PHP wasn't meant to be 'actionable', me thinks ... more like informative but still some info one might need to be aware.
Am gonna send you an offer you probably shouldn't refuse at this stage to your Email address as seen in your profile. Please watch for it and respond there.
'SoS', Ken
Hi
In your very first post you said, "having cron problems after upgrading to Moodle 4.2 from Moodle 4.1". How was cron running then?
In your very first post you said, "having cron problems after upgrading to Moodle 4.2 from Moodle 4.1". How was cron running then?
@ Mr. V .... and as a reminder to OP ...
Have been in direct communication with OP and gained ssh access to server.
A more pressing issue that needs to be resolved first ...
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
Ubuntu 18.04 LTS 'Bionic Beaver', one of the most popular Ubuntu releases, will reach the end of the standard, five-year maintenance window for Long-Term Support (LTS) releases on 31 May 2023.
Ubuntu 18.04 LTS 'Bionic Beaver', one of the most popular Ubuntu releases, will reach the end of the standard, five-year maintenance window for Long-Term Support (LTS) releases on 31 May 2023.
So OP has 30 days to move account to a newer OS. How one does that on DreamHost is up to provider.
Have communicated to OP above. Would recommend that be done first before addressing the issues the site has with cron - which is very interesting!
When cron.php script is run with the correct version of PHP as the accout user it runs just fine, except for this ... it runs and completes, then loops through "continuing to check for task" such as below.
Cron completed at 05:51:26 in 0.016347 seconds. Memory used: 45.9 MB. Continuing to check for tasks for 17 more seconds.
Ran 0 adhoc tasks found at Sun, 30 Apr 2023 05:51:27 +0000
Ran 0 adhoc tasks found at Sun, 30 Apr 2023 05:51:27 +0000
It will do that continuous and beyond Moodle's expectation of cron being run 1 time per minute.
Running checks.php shows:
CRITICAL: Tasks max fail delay (tool_task_maxfaildelay)
Status | Check
----------+--------------------------------------------------------------------
WARNING | Cron running (tool_task_cronrunning)
| The admin/cron.php script has not been run for 3 mins 14
| secs and should run every 1 min.
ERROR | Tasks max fail delay (tool_task_maxfaildelay)
| 4 task(s) failing
Status | Check
----------+--------------------------------------------------------------------
WARNING | Cron running (tool_task_cronrunning)
| The admin/cron.php script has not been run for 3 mins 14
| secs and should run every 1 min.
ERROR | Tasks max fail delay (tool_task_maxfaildelay)
| 4 task(s) failing
to be honest, have never seen anything like that before!!!
Anyone ever see that?
'SoS', Ken
It should be a new setting in 4.2, and i found it executing cron.php -h (https://tracker.moodle.org/browse/MDL-77186)
Site administration > Server > Tasks > Task processing > Keep alive time
The default is set to 3minutes and it’s the main cause of the cron log constantly (each second) filling of messages after the tasks run once.
I did’nt noticed this change until your message, but now I modified it to 0 and the cron behaviour it’s back to the “old way”.
Site administration > Server > Tasks > Task processing > Keep alive time
The default is set to 3minutes and it’s the main cause of the cron log constantly (each second) filling of messages after the tasks run once.
I did’nt noticed this change until your message, but now I modified it to 0 and the cron behaviour it’s back to the “old way”.
As a side effect of setting this to zero, my server uptime is lowering …
Thanks, Sergio! Got that Russ?
I don't have access tp the GUI admin of the moodle. Can that setting be added to config.php?
Thanks, in advance, Ken
Ken and Sergio,
I just changed the keep alive time to zero (0) minutes.
-- Russ
I just changed the keep alive time to zero (0) minutes.
-- Russ
Hi Ken
First thing is to identify whether the machine gives true super user access or some jail behind a Cpanel - in the best case a private Cpanel, the worst case is of course the hoster's Cpanel, which means that it is a shared host. At the rate the OP could jump from one to the other, I suspect a Cpanel, which'll leave me out.
Ubuntu 18.04: Yes, it is a well-tested, well-maintained OS, a LTS. EOL will not kill the system immediately. One can plan the exit route even medium term, means a 3-6 months.
Again, if it is a true VPS even a dist-upgrade is feasible. Ubuntu allows single-step dist-upgrades from LTS to LTS. But one doesn't have to tread such scary paths. Get a site backup, ask the hosting service for a new VPS, restore the site backup there. Either way, site backup part is a must - unless the OP is still at "proof-of-concept" stage. That is why I suggested a free MoodleCloud instance and avoid Unix/Linux gymnastics.
First thing is to identify whether the machine gives true super user access or some jail behind a Cpanel - in the best case a private Cpanel, the worst case is of course the hoster's Cpanel, which means that it is a shared host. At the rate the OP could jump from one to the other, I suspect a Cpanel, which'll leave me out.
Ubuntu 18.04: Yes, it is a well-tested, well-maintained OS, a LTS. EOL will not kill the system immediately. One can plan the exit route even medium term, means a 3-6 months.
Again, if it is a true VPS even a dist-upgrade is feasible. Ubuntu allows single-step dist-upgrades from LTS to LTS. But one doesn't have to tread such scary paths. Get a site backup, ask the hosting service for a new VPS, restore the site backup there. Either way, site backup part is a must - unless the OP is still at "proof-of-concept" stage. That is why I suggested a free MoodleCloud instance and avoid Unix/Linux gymnastics.
"I have the following line in .bash_profile as recommended by DreamHost:
alias php='/usr/local/php80/bin/php'"
.bash_profile is for the user level of the shell.
so what does one get using:
/usr/local/php80/bin/php -v
If you su to root what does the .bash_profile for that user look like? Same?
Rather then user .bash_profile think I'd use symlink for /usr/bin/php to version I want to run ... that then applies to all users on the system that have ssh/terminal access.
Cron job then could use simple: /usr/bin/php at front of cron command.
To find out what user your web server runs under, you have to look in main config file for apache.
That is kinda misleading as what really counts is how the account on the VPS is setup. So question: where is your moodle code located?
/var/www/html/
or in some other location.
Go to that 'location' and do ls -l config.php
On a CentOS 7 system where account is not in a user jail, an example and explanation:
-r--r--r--. 1 apache apache 1128 Feb 27 00:04 config.php
You can see the config php file is owned by user apache user which is the user under which the web service runs. The second 'apache' above is group.
To avoid issues with cron job for moodle, the cron job should run under the apache user on my server.
Truth ... I do things via root user (which isn't recommended by moodle docs) and my bu,up,upgrade bash shell scripts for moodle are owned by root user and only root user can see/execute them.
I run up more than upgrade as moodle releases new fixes to code and security updates frequently.
And IMHO, one cannot efficiently admin a moodle without command line and knowing the environment where hosted is necessary - and a step further, using git for versioning of Moodle will make admin of the moodle much less prone to human error!
'SoS', Ken
Ken, I doubt whether the cron is run as as the user the OP is logging in. In fact, the advice is to run it as the owner of the web processes. Even if they are the same, the crontab is not in a login shell, so the .bash_profile will not be read - I guess, pl. check.
@Russ - others encouraged to concur with recommendations (Mr. V?)
While attempting to make an sql dump backup of the DB discovered the DB is hosted on another IP address belonging to the same provider, but not same block of IP addresses as web server.
This error:
mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces
So that needs to be addressed on the DB server itself.
In config.php file of web server the remote DB server is referenced by FQDN ... not IP address. That means the DB server will do a DNS reverse lookup on every request it gets thus slowing down the speed. And config doesn't show any encrypted access to the DB server - meaning there is potential for a 'man-in-the-middle' exploit.
Thus, recommendation is ... when moving server to new OS, the DB also be moved to that new server and be setup as localhost. Queries will be more secure and never leave the new server as well as faster being localhost.
That also translates to having more resources on the new server ... both space and memory.
The entity is described such there is a good chance teachers will be using the moodle site while face-2-face with students - synchronously. That will require a bump not only in space but also memory of the new server. New server becomes an all-in-one which now must be configured to handle not only the number of clients accessing the web service but also the number of connections to the localhost DB server.
Right now, memory on the web server:
free -h
total used free shared buff/cache available
Mem: 31G 12G 2.0G 3.0G 16G 14G
Swap: 4.0G 825M 3.2G
total used free shared buff/cache available
Mem: 31G 12G 2.0G 3.0G 16G 14G
Swap: 4.0G 825M 3.2G
One can see the use of SWAP space ... which is never good .. and probably is mysql.
14G available could be eaten up quickly if the DB server moved to same server as web service. So if the new server has equal memory, 31G, strongly suggest immediately monitoring to see if memory needs bumping upwards due to move of the DB server to localhost.
The other thing I'd strongly advise against ... OP (you Russ) said you removed the hosting providers panel ... first, don't know how that was possible cause account didn't have ability to sudo to root, but ... the panel they provide, which I have not seen, is more than likely the best tool for tweaking many things you will need to tweak - like the memory allocated to the localhost DB server.
Getting the panel re-installed on new server will have to be handled by hosting provider as that is specific to where you host ... imagine no OS repo exist where you the OP could do that!
Others encouraged to make contributions/suggestions for OP ... this is my FREE 2 cent advice!
'SoS', Ken
>>> The other thing I'd strongly advise against ... OP (you Russ) said you removed the hosting providers panel ... first, don't know how that was possible cause account didn't have ability to sudo to root, but ... the panel they provide, which I have not seen, is more than likely the best tool for tweaking many things you will need to tweak - like the memory allocated to the localhost DB server. <<<
I have probably used a poor word choice again. It appears in my quick browsing that some providers have an app called cpanel or something like that that manages cron jobs. Some replies have questioned how I could delete the cpanel and still have cron jobs.
To be clear: I did not delete any application. When I log on to DreamHost, I am at an web site whose home page is called the DreamHost Web Panel. It has menu options for buying new domain names, setting up web hosting, and more. One of those options is called "Cron jobs." When you pick that option, you can enter many of the parameters for a cron job that you are cryptical if you use crontab.
For Moodle 4.1 and part of 4.2, I was running the Moodle cron job from this application. Someone suggested that because it was unclear which php version was running under that application, I should use crontab instead and explicitly tell crontrab to use (me) as the user. Then I could control which php version is used.
So, I deleted the cron job that was in that app, and I recreated it in crontab. The KB article said I could have my own crontab file, which takes precedence over the system crontab file. So I created one.
So no capabilities have been deleted. I can still set up a cron job in DreamHost's Cron job application, or I can set one up in crontab. BUT: where the metadata for the job is stored is different for these 2 apps, and I think (but can't be certain) that much of the running environment is different, too.
-- Russ
I have probably used a poor word choice again. It appears in my quick browsing that some providers have an app called cpanel or something like that that manages cron jobs. Some replies have questioned how I could delete the cpanel and still have cron jobs.
To be clear: I did not delete any application. When I log on to DreamHost, I am at an web site whose home page is called the DreamHost Web Panel. It has menu options for buying new domain names, setting up web hosting, and more. One of those options is called "Cron jobs." When you pick that option, you can enter many of the parameters for a cron job that you are cryptical if you use crontab.
For Moodle 4.1 and part of 4.2, I was running the Moodle cron job from this application. Someone suggested that because it was unclear which php version was running under that application, I should use crontab instead and explicitly tell crontrab to use (me) as the user. Then I could control which php version is used.
So, I deleted the cron job that was in that app, and I recreated it in crontab. The KB article said I could have my own crontab file, which takes precedence over the system crontab file. So I created one.
So no capabilities have been deleted. I can still set up a cron job in DreamHost's Cron job application, or I can set one up in crontab. BUT: where the metadata for the job is stored is different for these 2 apps, and I think (but can't be certain) that much of the running environment is different, too.
-- Russ
Official Moodle docs on how to setup cron job
https://docs.moodle.org/402/en/Cron
IMPORTANT: Do not skip setting up the cron process on your server for your Moodle. Your site will not work properly without it.
It is recommended that the cron is run every minute
More detail
https://docs.moodle.org/402/en/Cron_with_Unix_or_Linux
Question about 'meta-data' ... vr. 4 does have a report for cron.
And, if one follows the direction for setup of cron, that should have resulted
in getting an email message about cron once every minute. Don't think you'd want that. Unless your cPanel setup has a way to quiet that and log.
At one point in time, your system ran the cron job and logged the output.
Somewhere in /home/licc_admin/logs/yourdomain.org/
What I have done for you in admin/cli/ of moodle code is a bash shell script
called runcorn
source runcron
and now that you've fixed that looping issue (thanks again Sergio), it runs just fine:
clip of tail end:
Execute scheduled task: Background processing for scheduled allocation (workshopallocation_scheduled\task\cron_task)
... started 19:36:02. Current memory use 35.3 MB.
... no workshops awaiting scheduled allocation. ... used 1 dbqueries
... used 0.0012938976287842 seconds
Scheduled task complete: Background processing for scheduled allocation (workshopallocation_scheduled\task\cron_task)
Ran 0 adhoc tasks found at Sun, 30 Apr 2023 19:36:02 +0000
Cron run completed correctly
Cron completed at 19:36:02 in 1.329411 seconds. Memory used: 35.2 MB.
Your notifications screen in moodle should not be complaining now if you have set the cron job in your cPanel properly.
https://docs.moodle.org/402/en/Cron
IMPORTANT: Do not skip setting up the cron process on your server for your Moodle. Your site will not work properly without it.
It is recommended that the cron is run every minute
More detail
https://docs.moodle.org/402/en/Cron_with_Unix_or_Linux
Question about 'meta-data' ... vr. 4 does have a report for cron.
And, if one follows the direction for setup of cron, that should have resulted
in getting an email message about cron once every minute. Don't think you'd want that. Unless your cPanel setup has a way to quiet that and log.
At one point in time, your system ran the cron job and logged the output.
Somewhere in /home/licc_admin/logs/yourdomain.org/
What I have done for you in admin/cli/ of moodle code is a bash shell script
called runcorn
it uses the full path toe php 8.0 cli and the cron.php script in code/admin/cli/
run like so:source runcron
and now that you've fixed that looping issue (thanks again Sergio), it runs just fine:
clip of tail end:
Execute scheduled task: Background processing for scheduled allocation (workshopallocation_scheduled\task\cron_task)
... started 19:36:02. Current memory use 35.3 MB.
... no workshops awaiting scheduled allocation. ... used 1 dbqueries
... used 0.0012938976287842 seconds
Scheduled task complete: Background processing for scheduled allocation (workshopallocation_scheduled\task\cron_task)
Ran 0 adhoc tasks found at Sun, 30 Apr 2023 19:36:02 +0000
Cron run completed correctly
Cron completed at 19:36:02 in 1.329411 seconds. Memory used: 35.2 MB.
Your notifications screen in moodle should not be complaining now if you have set the cron job in your cPanel properly.
And ... see that we are planning to wipe out this server and start from scratch on a new host. Uhhhh, you could use the full course backups (including users) you will make just before wiping out the old server to repopulate courses on new server.
Ok, what started as an offer for a free look-see and recommend, then grew to I do and explain (direct email exchange for items that can't be shared in forums), and now back to forum - with the aid of Sergio a fix and Mr. V for his comments, I'd say we're done with this saga (for now). Aren't we?
More to come in future and located - hopefully - in a new thread/saga there!
'Spirit of Sharing', Ken
Ken wrote, "I'd say we're done with this saga (for now). Aren't we?"
Indeed, if we were using trouble tickets, I would say that you could close it.
Indeed, if we were using trouble tickets, I would say that you could close it.
Thank you Ken, Visvanath, and Sergio. A small college in the world's fifth poorest nation is struggling to improve the quality of its education and to bring its technology into the second decade of the 21st Century. Your help was gratefuly appeciated!
-- Russ Schwartz
In reply to Russell Schwartz
Re: cron failing after 4.1 to 4.2 upgrade [Solved]
by Visvanath Ratnaweera -
Hi Russel and all
I allowed myself to add a [Solved] tag to the subject as per the Site policy.
The remaining question is, what did the saga tell us. What I learnt was, although as the birthplace of Unix, PDP, would have been the deepest place on earth to connect with Unix, VAX/VMS is the wrong port of call.
No, seriously, this has been another round of a familiar pattern: The beginner, who is primarily a teacher, has higher level objectives than the DIY aspects which are purely technical. Unless the DIY is the main focus the teacher should delegate technical part at least at the beginning. There are simply too many possibilities under the broad term "hosting".
Coming down to poor countries, obviously they have to work harder than the affluent. In this connection I must repeat a suggestion I brought earlier, the MoodleBox, which is a portable Moodle server which doesn't even need the Internet!
In reply to Visvanath Ratnaweera
Re: cron failing after 4.1 to 4.2 upgrade [Solved]
by Russell Schwartz -
Visvanath,
Your summary statement was so insightful that I gasped! You went right to the root cause of the problem.
Years ago, I was an IT guy, but now I am a teacher with few resources. Our school does not have an IT department. If Moodle works, it's because I make it work. However, as the old saying goes, "A fool with a tool is still a fool." And I am a fool with respect to Linux system administration. My curriculum and instruction work, as well as my teaching and (organizational) administrative duties consume my time and attention. When forced to do systems work, I do not do it well, and I make careless and (in this case) impulsive mistakes.
For this reason, I will very seriously consider Moodle Cloud when we scale up beyond my pilot course. I want something that "just works" and I don't have to think about it. If anything goes wrong, a phone call or email will trigger someone who knows what they are doing to fix it.
As for the MoodleBox concept, it does exist conceptually. The RACHEL server by worldpossible.org is a self-contained LMS as you mention. It has its own LMS, but we could easily fork a Moodle-based implementation. Unfortunately, the server is not cheap at $500 USD. But it's a start.
All the best,
-- Russ Schwartz
Your summary statement was so insightful that I gasped! You went right to the root cause of the problem.
Years ago, I was an IT guy, but now I am a teacher with few resources. Our school does not have an IT department. If Moodle works, it's because I make it work. However, as the old saying goes, "A fool with a tool is still a fool." And I am a fool with respect to Linux system administration. My curriculum and instruction work, as well as my teaching and (organizational) administrative duties consume my time and attention. When forced to do systems work, I do not do it well, and I make careless and (in this case) impulsive mistakes.
For this reason, I will very seriously consider Moodle Cloud when we scale up beyond my pilot course. I want something that "just works" and I don't have to think about it. If anything goes wrong, a phone call or email will trigger someone who knows what they are doing to fix it.
As for the MoodleBox concept, it does exist conceptually. The RACHEL server by worldpossible.org is a self-contained LMS as you mention. It has its own LMS, but we could easily fork a Moodle-based implementation. Unfortunately, the server is not cheap at $500 USD. But it's a start.
All the best,
-- Russ Schwartz
In reply to Russell Schwartz
Re: cron failing after 4.1 to 4.2 upgrade [Solved]
by Visvanath Ratnaweera -
Hi Russel
The summary was easy. See how long I have been repeating the statement.
The summary was easy. See how long I have been repeating the statement.
Coming back to your application, it looks like your audience has Internet. In that case you don't need MoodleBox, RACHEL, etc. Still I allow myself some elaborations on what you've said:
> As for the MoodleBox concept, it does exist conceptually.
It is more than just a concept. An OS image exists. You write it to a storage medium, micro-SD, USB memory stick, SSD drive, etc. insert in in to / connect to a Raspberry Pi and switch on.
OK, lately it had become expensive. The R Pi scarcity had driven the price high.
> The RACHEL server by worldpossible.org is a self-contained LMS as you mention. It
has its own LMS,
It contains many unrelated web applications.
> but we could easily fork a Moodle-based
implementation. Unfortunately, the server is not cheap at $500 USD. But
it's a start.
But you can also download the content and run your own RACHEL.
That
could be a Raspberry Pi too (price saving). Now the big curiosity: You can run RACHEL on
a MoodleBox. Then you have both:. The content of RACHEL and the (empty)
classrooms in Moodle.
I could ask DH to host Moodle and the database on the same server, but I don't think they are likely to do that. From past newsletters, I know they have strategies for managing their servers...
Visvanath asked me to consider using Moodle Cloud. Right now, I have just 2 courses and 2 "sandbox" courses that I am using for proof-of-concept. When the semester ends in June, I will wipe Moodle off the site and start over with a fresh LTS version. Later, if I decide that online learning is feasible at the school in the short-term, then I will seriously consider Moodle Cloud. I am 100% in favor of delegating system administration to somebody else. I retired from IT in 2011, and now I am a Curriculum and Instruction developer. In days gone by, I managed PDP-11s and VAXen, but my knowledge of Linux is pitifully small. Ken was commenting that I don't have sudo access on the server. Thank goodness! If I did, I'd probably mess things up even more: ;)
-- Russ
Visvanath asked me to consider using Moodle Cloud. Right now, I have just 2 courses and 2 "sandbox" courses that I am using for proof-of-concept. When the semester ends in June, I will wipe Moodle off the site and start over with a fresh LTS version. Later, if I decide that online learning is feasible at the school in the short-term, then I will seriously consider Moodle Cloud. I am 100% in favor of delegating system administration to somebody else. I retired from IT in 2011, and now I am a Curriculum and Instruction developer. In days gone by, I managed PDP-11s and VAXen, but my knowledge of Linux is pitifully small. Ken was commenting that I don't have sudo access on the server. Thank goodness! If I did, I'd probably mess things up even more: ;)
-- Russ