Hello,
I just configured a task for cron in our Cpanel. Moodle says to run cron every minute but I noticed that our Cpanel inbox is receiving emails every minute which occupies space. Is it ok if I set the task for every 30 minutes?
Thanks.
To not receive emails, end your command line with "> /dev/null."
In my case, my command line looks like "/usr/local/bin/php /home/{user}/public_html/moodle/admin/cli/cron.php > /dev/null".
In my case, my command line looks like "/usr/local/bin/php /home/{user}/public_html/moodle/admin/cli/cron.php > /dev/null".
I will just reply here... Thanks to all your responses.
I changed the frequency for every 5 min first, then later to every minute. But I don´t know why it reverts to every five minutes every day and I have to change it every time.
I deleted the cron job and created a new one but still it reverts to every 5 minutes.
Guess I will have to ask my hosting provider about this.
Again, thanks to all.
I changed the frequency for every 5 min first, then later to every minute. But I don´t know why it reverts to every five minutes every day and I have to change it every time.
I deleted the cron job and created a new one but still it reverts to every 5 minutes.
Guess I will have to ask my hosting provider about this.
Again, thanks to all.
Needs to run every minute.
Alternate to sending cron output to la-la-land ... if you have command line access to server (ssh or cPanel terminal) + a true VPS where you are in control of server ...
touch /var/log/moodle-cron.log
Then in cron job setup redirect to the log:
> /var/log/moodle-cron.log
No email sent and one can then have the advantage of watching that log in realtime via command line:
tail -f /var/log/moodle-cron.log
'SoS', Ken
Yep, Ken, this is appreciated advice.
When I did this "touch" on my experimental server from Terminal, I had to be logged in to my experimental server as "su."
When I did this "touch" on my experimental server from Terminal, I had to be logged in to my experimental server as "su."
Welcome! Now remember I said 'IF' and gave some criteria.
VPS's with many hosting providers are not totally turned over to customer ... evidently GoDaddy is one .. have never had a GD hosted server and never been 'invited' into one to see.
For others ... 'su' means substitute user. The user one logs in with is usually a customer user ID with password. If that customer user ID is part of the 'sudoers' group, that customer user ID can 'su' to root user without having to know/use the root password. But some systems do not make the customer user (account) a member of sudoers - and cPanels may not offer a mini-app to do anything about that. (Webmin does, BTW) In affect, user/customer is in a user jail (home/public_html) ... there is restriction ... even if providers say there isn't any restrictions!
If they did make customer ID part of sudoers, it's easy ... sudo -s (the -s means 'stay') and user provides their customer login password, the terminal prompt will change to 'root'. You are now in the system as root. BTW, have to type 'exit' twice now ... once to get logged out as root ... and once more to get logged out as customer ID.
The important part ... sudo to root means you can edit config files that cPanel doesn't give you permissions to do ... knowing that if one uses cPanel again to configure whatever, your command line sudoer changes will be lost.
The other 'catch 22' with some VPS's ... one does not know the superuser credentials to the DB server. Now if VPS's do offer support by hosting techs there is a hidden my.cnf that does contain that info. They have to know in order to provide support on MySQL/MariaDB issues. They really don't want to go there ... support provided means time spent and that translates to $. Some php scripts in code/admin/cli/ that work with database to fix them require superuser creds .... those scripts use info from moodle's config.php file for creds. If those creds are not superuser then scripts cannot do there job.
Seems to me that moodle has always been onwards upwards ... does more .. requires more ... and only moodle aware providers can adjust for that ... but they don't.
Tough road to travel claiming that code (and efficient admin of that code) can run on anything ... right out of the shrink wrap! (not true)
These environmental issues is exactly why things like Softac exist ... and why customers that use such get in between a rock and a hard place!
It is what it is ... hard to get specfic information about leasing when one is talking to a sales person. It's only after one gets a lease (VPS) that one discovers what's missing ... and they only way they would know that is to run something like VirtualBox on their laptop with an OS that is same flavor and version as what is provided by hosting (which is also why am not a 'fan' of localhost moodle in MAMP or other such).
LIke I said ... it is what it is! :|
'SoS', Ken
I am working on a new GD VPS right now because I will be buying a new VPS to replace my old one very soon, so this is why I refer to it as "experimental."
Hopefully, this time around, I can make a video showing how to install Moodle, manually, on (this brand of) a VPS. Sure, it is very specific, but it might be helpful. With this video, others (like you) might get a sense of what is involved. Of course, it will also give folks a chance to give me feedback.
So, on this VPS, one needs to add a particular user to the "wheel" group in order to be able to do a "su."
I also discovered that if I then issue the "touch" command, as you suggested, that a user's cron did not, by default, have the permission to write to this log file created by root. I decided to move this log file under the user, which is probably a better place for it.
Hopefully, this time around, I can make a video showing how to install Moodle, manually, on (this brand of) a VPS. Sure, it is very specific, but it might be helpful. With this video, others (like you) might get a sense of what is involved. Of course, it will also give folks a chance to give me feedback.
So, on this VPS, one needs to add a particular user to the "wheel" group in order to be able to do a "su."
I also discovered that if I then issue the "touch" command, as you suggested, that a user's cron did not, by default, have the permission to write to this log file created by root. I decided to move this log file under the user, which is probably a better place for it.
So, right now my cron entry is as follows, where {user} should be the actual user:
/usr/local/bin/php /home/{user}/public_html/moodle/admin/cli/cron.php > /home/{user}/moodle-cron.log
One thing that I wonder about is if the ">" should be a double >>? Will cron entries be appended to the log file when only a single > is used?
A single > is a redirect. A double (>>) is as you have said is 'appended' (translate in layman's terms ... added to the bottom of).
Result of a >> is a very large log file ... could reach GiG's if logging on server isn't configured to cap size of log files and syslog (the dameon that does/crntrols logging) doesn't know of the manual moodle-cron.log file created and to rotate it when reaching cap size.
Location of log files ... on stand alone Linuxes (most) use /var/log/ but on jailed systems per user one will see an aliased directory in /home/ of the account. And one won't see all the logs, just the apache logs.
In your case, redirecting to a directory where the cron job running under user login could write to it is only option ... and putting it in /home/customerlogin/ was wise .... can't see it via web.
Some 'brain dead systems' (in my book) even have php set to log errors in the directories where the error occurs ... on some systems I had to do a bash script to find all 'error_log' files in any moodle code directory. That might be configurable to a single log file but I didn't have the time to explore all that considering 'customer' having issues wanted it fixed yesterday.
Here again, the only way one can see differences is to run Virtualbox on local system and the distro that's the same as hosting ... LTS el7 and Ubuntu whatever LTS version is.
We've talked about videos before ... moodle can be installed using nothing but cli ... those make for very boring vids - best just to put the commands in a blog (which many have done already). Or, you could now do this ... use a Moodle and H5P vids ... at appropriate times in those vids, a pause showing the text of the command issue. User could copy and paste that. When op completes that step, back to H5P vid and continues to next step.
Now that would be not only 'talking the talk' of Moodle, but 'walking the walk' of Moodle by using Moodle itself!!!
The trouble with following those commands ... even ones provided by Moodle docs ... variables to hosting. Sometimes users find such a page for Ubuntu and try using same commands on CentOS EL7/8 or vice versa. Can do but have to substitute things like apt-get with yum or dnf - thus advice on learning command line package manager - as well as ownerships/permissions.
Anyhoo ... like I said ... it is what it is! Question for OP ... just how deep does one want to go? For me, that is already answered ... I want the most efficient way ... with human error removed as much as possible. And for that, CLI is the answer.
Ok, have hijacked this thread enough ...
'SoS', Ken
Yes, that was what I was expecting, a very large log file, if all these cron jobs got appended.
Yes, on this VPS and given a "user," each user has a "logs" folder in their own account. I am now sending cron to that location.
All of this could be useful to the OP. At least someone other than I have tagged your reply useful.
Yes, on this VPS and given a "user," each user has a "logs" folder in their own account. I am now sending cron to that location.
All of this could be useful to the OP. At least someone other than I have tagged your reply useful.