Grav: Scheduler / cron relying on shell commands

[ulab]

I am not a big fan of Grav having to execute shell commands to check for or create cron jobs. This is an issue especially on hosts that disallow exec(), proc_open() and such for security reasons and resulted in fatal errors on my box when navigating to Tools / Scheduler.

Being the admin on my server, I was able to allow the functions, but this is something that might hurt a lot of people.

After manually adding a cron job, which does not necessarily have to be inside of the webserver-users cronjob table (depending on the hoster), I noticed that Grav still reports "Cron Not Available", because it checks by running cron -l which of course does not list a cronjob that is in /etc/cron.d/zzz-customers.

Perhaps it is an option to have the cron script touch() a file on each run and check if it is older than 2 minutes to see if a cron job is running regularly instead?

[dgellow]

To add to what @ulab said, a dependency on cron -l is causing issues in chrooted environments (such as a chrooted php-fpm).

Also, systemd timers or other schedulers exist as alternatives to crontab, the suggested touch() on a file would work with them.

[rhukster]

Cron is really the only semi-universal solution that is 'usually' available on servers. Of course if a server is chrooted, or cron is locked down, it's not going to work. But then nothing is on those hardened servers.

I looked at all the available options during the development of the scheduler, and all the reliable options relied on cron under the covers. If you find something that is better, then I'll evaluate it and see if its something we could use as an alternative in future versions.

[ulab]

This issue is not against having cron jobs per se, but the scheduler relying on a cron command to check if any method of recurring jobs are being run.

I was able to create a cron job in a different way for example, but the scheduler still says "Cron Not Available".

The suggestion is to just check the modification date of a specific file instead of running "cron -l".

This way you can have different methods of recurring jobs as long as they touch the file which allows the scheduler to identify they are being run regularly.

[dgellow]

The solution suggested by @ulab only requires the cronjob (or equivalent) to do a touch /path/to/specific/file in addition to php bin/grav scheduler . That removes the need for both exec and crontab.

[ulab]

Even php bin/grav scheduler could touch the file directly when its run.

Then as long as some kind of mechanism runs the schedular regularly, the system would be able to check if it is run without having to rely on the cron -l command.

[bkraegelin]

I just figured out the same problem on my shared hosting system...

Most other CMS provide a cron.php script, which may be called regularly from any cronjob service on the internet (or may be called using wget http://localhost from cron)

What about this idea? Maybe as an additional plugin like Poor Man's Cron?