-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: crontab permission error #19
Conversation
Fixed problem of displaying `cron not avaliable` warning in Tools -> Schedular page
Fix the problem of crontab not really working for the user that runs php
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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!
Hi! Sorry for late reply. Of course I am glad to explain the change.
The However in docker a corntab will not really run unless it's root. So the I think grav's control console is not designed for working inside a docker container, that's why this code looks ugly :)
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! |
Thanks, interesting :) |
Fixed problem of displaying
cron not avaliable
warning in Tools -> Schedular page