fix: crontab permission error

[tojo17]

Fixed problem of displaying cron not avaliable warning in Tools -> Schedular page

[hughbris]

@toshichi :
Could you explain a few details about this commit please? I'm asking because I'm experiencing similar issues with a caddy grav image I am trying to build.

Firstly, what do the comment lines "# Setup cron to make control console green" and "# Setup cron that really works" mean? Did you need to install a root crontab to make cron work? Why didn't you get rid of the webserver user's crontab in that case? When I tried running Grav's scheduler as root in my setup, I ended up with file permission problems.

Going slightly off-topic, when researching my problems getting a cron daemon to run in my containers, I read a lot of opinions (by Docker purists IMO) that cron should run on the host machine or another container with access. I get their point, but think that this is one of those pragmatic cases where cron belongs with the main service being run, plus doing it that way adds a step to setting up a Grav instance. Keen to know you (or @dsavell or anyone's) opinion on this.

Cheers!

[tojo17]

@hughbris

Hi! Sorry for late reply. Of course I am glad to explain the change.

Firstly, what do the comment lines "# Setup cron to make control console green" and "# Setup cron that really works" mean? Did you need to install a root crontab to make cron work? Why didn't you get rid of the webserver user's crontab in that case? When I tried running Grav's scheduler as root in my setup, I ended up with file permission problems.

The # Setup cron to make control console green means, in the control console of Grav, it detects the crontab jobs of current user running grav (in this docker image, xyz). If the current user's crontab file contains the command it wants, grav will color the status in control console as green. If not, there will be a red notice says your crontab config is not correctly configured (or some similar words). That's why I kept this line rather than removing it.

However in docker a corntab will not really run unless it's root. So the # Setup cron that really works adds another same corntab job to root's crontab list.

I think grav's control console is not designed for working inside a docker container, that's why this code looks ugly :)

Going slightly off-topic, when researching my problems getting a cron daemon to run in my containers, I read a lot of opinions (by Docker purists IMO) that cron should run on the host machine or another container with access. I get their point, but think that this is one of those pragmatic cases where cron belongs with the main service being run, plus doing it that way adds a step to setting up a Grav instance. Keen to know you (or @dsavell or anyone's) opinion on this.

Yes you are right. A crontab running as a background service in docker is unreliable, it could end up anytime, even if runned under root. When I committed this I did some test but the crontab seems to work well in the background as root, so I wrote it in this way. I am not using grav right now, if you find it unstable in fact, please let me know. I think the best practice is to start another container and run crontab foreground.

Maybe getting a docker-compose file with a shell script entry makes it easier, like what they do in nextcloud's docker.

Have a good day!

[hughbris]

Thanks, interesting :)