Posts made by Visvanath Ratnaweera

Picture of Particularly helpful Moodlers Picture of Translators
Hi

I am not talking of minimum requirements. (What is the weakest CPU Moodle would run?) I am talking of hardware resources and system software. Quoting https://moodle.org/mod/forum/post.php?forum=94:
Please include as much background information as possible about your hardware, the operating system, the web server, the database server, the PHP scripting framework, etc. If your machine is virtualized, also mention the host hardware, the operating system, the virtualization technology used and the resources assigned to the virtual machine. If you use a hosting service, mention either the hosting provider and the package or the resources as advertised.
Picture of Particularly helpful Moodlers Picture of Translators
They may be supportng Linux hosting but the ASP in the name was suspicious so I checked.
===
ASPHostPortal.com is Microsoft No #1 Recommended Windows and ASP.NET Spotlight Hosting Partner in United States. Microsoft presents this award to ASPHostPortal.com for ability to support the latest Microsoft and ASP.NET technology, such as: WebMatrix, WebDeploy, Visual Studio 2012, .NET 4.5.1/ASP.NET 4.5, ASP.NET MVC 5.0/4.0, Silverlight 5 and Visual Studio Lightswitch.
===
Make your own judgement!
Average of ratings: Useful (1)
Picture of Particularly helpful Moodlers Picture of Translators
Hi

This kind of updates are valuable for others who are having the same problem.

If I may add a few clarifications in Moodle- resp. Unix-speak:
- NOT doing 1. You are right. If you plan to call the cron.php from within the system, the path is $moodle/admin/cli/cron.php. But then don't need the web(HTTP)-based cron.php, which is $moodle/admin/cron.php. See https://docs.moodle.org/29/en/Cron.

- NOT doing 2. /bin/usr/php (shouldn't it be /usr/bin/php?) is not a prefix. It is the program which is kicked by cron, in this case it is the PHP interpreter. See the Moodle Doc mentioned earlier.

- NOT doing 3. It is the web-based cron.php which is password protected. Since you make use of the CLI cron.php, you don't have to worry about this password.

I think it is the /usr/bin/php in place of the /bin/sh (or /bin/bash or whatever) in your cron table which solved the problem.