Hey guys, I have a new cronjob created, and it is in /etc/cron.d directory, it is a simple php script. Here is my ispc_web1 Code: MAILTO='' SHELL='/bin/sh' * * * * * web1 /usr/bin/php -f /var/www/clients/client1/web1/web/crontest.php >>/var/www/clients/client1/web1/private/cron.log 2>>/var/www/clients/client1/web1/private/cron_error.log #domain.com Script is never executed, can you plesase give me some info or directions if I am doing something wrong. Machine OS is Centos 7, if it helps. Thanks in advance
if it never gets executed ( includes you've made sure cron does echo something at the very first, which doesn't show up in the log ) check wether your crond is running at all, you may make that one sure by Code: $systemctl enable crond && systemctl restart crond next thing would be to check wether the path to php is correct Code: $which php should return that. And last but not least, is there an issue with the php file, have you tried running that manually using php-cli ? at least debian does have different php.ini for that and in rare occasions it can make a difference, example: you use short open tags which is ok for fpm/httpd but not for cli
If you need to execute a php script I suggest you use HTTP to access the file, so create a cronjob in ISPConfig and use http://client1domain.tld/crontest.php as command.
that's a terrible idea. first of all you face every issue with maximum execution time, some crons do run for a while second thing is: cronjobs may be designed to run a specific amount of time only, that's why it's bad design to let it be accessible in your /web-folder, even if somehow password protected. put your crons into /private-folder
The solution @scolak posted has exactly the same problems you are talking about with one major thing added: most people do not manage to get it working. So you should maybe reconsider your first answer @ztk.me because 1) you don't criticize it and 2) your suggestions solve his problem...
basicly the only issue with using full cron is, he has the file in /web but that can easily be changed wheres using http:// cron still puts extra load to webserver and limits the execution time / make it dependale on httpd-service. I don't know, I've seen a lot ppl whose technical skills are ... non existent - but they managed to install crons like that with no problems. The /etc/cron.d/webxy file is created by ispconfig regardles wether you choose full cron or http, it just looks different then. Since I don't see any issue in that file I'd guess crond is not running for some reasons, maybe an upgrade disabled it or it was never enabled, especially on centos you have to enable lots of things explicitly and can be easily forgotten if you don't do the setup howto carefully.
max allowed execution time of php scripts can be altered.... as for it being in the web: simply protect by htacces and then use http(s)://user:[email protected]/path/to/secure/script
yes it can be altered but there is a reason for it to be not too long htaccess is a possble workaround but doesn't move the script outa /web dir - could be exploited by some bad script. But that wasn't the main reason. http-cronjobs are imho just a bad design option in general for probably many more reasons.
yes, there might be aswell reasons to actually use http crons, but I bet the majority asking questions won't need them. encouraging someone to change local cron to be an http cron is something I can't support + likely it wouldn't solve the issue anyhow. Those who need/write crons meant to be called by cronjob are probably hosting some kind of API which usually should respond fast enough or is setup in a special manner to support long enduring requests if it's like some kind of well known currency processor having troubles with even sending account balance within a reasonable time
