I understand that the location of the default Hestia admin cron commands is
/usr/ local/hestia/bin
However, I can not find the location where Hestia user xxxx cron commands are located. I am hoping someone can tell me the path to where they are located in the file system.
Cron and Hestia commands (CLI Core Scripts) are two different things. So, your question is not clear. Would you like to rephrase and add the reason for asking (I mean what you need to do).
Just shooting in the dark what you want to do… If you want to set some cron jobs for a user, login to Hestia Web UI with that particular user and click on the CRON tab.
I am sorry. I will try to be clearer. I have a Debian 10 VPS on which I installed the latest version of Hestia. I created a Hestia user and logged into the user account and created a Moodle website. Moodle requires a Moodle cron job. So I clicked on the cron tab and added the cron job. This cron job has created errors and not ran properly. I have been trying to resolve these errors for more than a week. My goal is to figure out how to get Hestia to work with Moodle. Moodle has some major challenges when it comes to the Moodle cron job. There is little documentation and more than 5000 questions about the process on the Moodle forum! I am hoping to use Hestia to over-come some of these challenges.
In researching Hestia default cron jobs, CLI core scripts, I noted that Hestia cron commands began with sudo followed by the cron command. In order to use sudo without the password, Hestia assigns the admin user to the /etc/sudoers special group.
The password is not required for the path
/usr/local/hestia/bin
Since this is where the Hestia admin default cron jobs are run, they can be run without the password.
My hope is to do the same process for my Hestia moodle user. But it has become clear to me that user cron commands are not placed in the path
/usr/local/hestia/bin
The user cron commands have to be somewhere in the file system. I have spent hours looking for this location without success. Once I find the path to the user cron commands, I intend to add that path to the Hestia user in the etc /sudoers file to that I can use sudo at the beginning of the command without needing to add the user password.
Any help in finding the user cron command path would be greatly appreciated.
sudo is for getting elevated permissions. Moodle script are located in the /home/user/web/domain/public_html/ folder probably. If you need to run it with php / curl it can be found in /usr/bin/php or /usr/bin/curl
Eris,
You are correct. The moodle cron script is located in
/home/user/web/domain/public_html/admin/cli/cron.php
I have ran it with php7.4 located at
/usr/ bin/php7.4
I guess you are saying that a user does not need elivated privileges and therefore does not need to add sudo to their cron command. Here is the cron command I am using:
/usr/local/bin/php7.4 /home/myserveruser/public_html/moodle/admin/cli/cron.php
While this works, moodle insists on running it every minute which leads to an email being sent every minute which floods the moodle admin email box. To get the emails not sent, moodle forum members recommend to add >/dev/null to the end of the command:
/usr/local/bin/php7.4 /home/myserveruser/public_html/moodle/admin/cli/cron.php >/dev/null
This leads to a once a day error email being sent that the cron command cannot find or connect to the database. Other moodle forum members recommend adding >/dev/null 2>&1 to the end of the command:
/usr/local/bin/php7.4 /home/myserveruser/public_html/moodle/admin/cli/cron.php >/dev/null 2>&1
This seems to be working when viewing the Moodle admin panel. But there are no emails sent with or without errors and I have no idea why adding 2>&1 suddenly makes the command work.
I had hoped that copying what Hestia does with its cron jobs that I could overcome this problem. But if I should not add sudo to the beginning, then I guess I will need to find some other way to get Hestia and Moodle to work together.
The 2>&1 at the end, is used to redirect both outputs to /dev/null (the regular command output and the error output). It is not “making the command work”. It is just hiding the error message(s).
I suppose having just the > /dev/null does what you want it to do. No? I would recommend to not redirect the error output (2>&1) because if you do, you will not know when something went wrong. Either bear with the error once per day, or find out what is causing it and fix the database connection issue.
P.S. /dev/null is the null device that ignores/discards everything that is going there.
Felix,
I agree with you 100 percent. Adding 2>&1 at the end is not a good long term solution because I will no longer get error messages. But strangely, it does seem to result in the moodle cron job being active in updating the moodle database. At the same time, >/dev/null causes the moodle cron job to not run and the moodle database to not be updated. In summary:
The moodle cron command updates the database when not using >/dev/null but sends emails every minute.
The cron command does not update the database when using just
/dev/null at the end.
The cron command does update the database when using
/dev/null 2>&1 but then I will no longer get any error messages should there be a problem in the future.
However, I have been using
/dev/null
(which has no spaces) and you seem to be suggesting
/dev/null
which has a space between the arrow and the /dev/null
I am wondering if adding the space as you do might make a difference. I am going to try this and I will report back in a few hours with the result.
(the reason the result will be delayed is because using
/dev/null
creates an error which causes the moodle cron to be run once every 24 hours instead of once a minute).
NOTE: for some reason the arrow I am putting before /dev/null is not appearing above. But my question remains: should there be a space between the arrow and the /dev/null?
Put the commands between 2 Grave accent “`”
I have two Moodle websites set up for two different Hestia users. I set the cron command for one to add the space between the arrow and /dev/null. For the other moodle site cron command, I did not add the space between the arrow and /dev/null. Either way, I eventually get this error:
Exception ignored in shutdown function core\lock\mysql_lock_factory::auto_release: Error reading from database
The cron command runs without error and can read from the database without the /dev/null.
Also the cron command updates the database correctly even with the /dev/null error. so it obviously can read from the database.
Also the cron job runs and updates the moodle database without any notification if I add 2>&1 to the end of the command. However, I do not want to do this because I do want to be notified if there are REAL errors.
So my questions now are:
what could possibly cause this error???
Also, Hestia cron screen has a button called “Turn off notifications”. Does this button turn off all notifications including error notifications - or does it just turn off cron job notifications that succeed without errors???
I will do some testing with my two Moodle Hestia websites and report back in a couple of days. But if someone knows the answer to either of these questions, I would appreciate the help.
Turn of notifications disables the mail send by the cron.
Does it also disable error notifications?