Cron job problems

Discussion in 'Server Operation' started by scolak, Oct 6, 2017.

  1. scolak

    scolak New Member

    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 :)
     
  2. ztk.me

    ztk.me ISPConfig Developer ISPConfig Developer

    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 ;)
     
  3. HSorgYves

    HSorgYves Active Member

  4. ztk.me

    ztk.me ISPConfig Developer ISPConfig Developer

    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
     
  5. HSorgYves

    HSorgYves Active Member

    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...
     
  6. ztk.me

    ztk.me ISPConfig Developer ISPConfig Developer

    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.
     
  7. sjau

    sjau Local Meanie Moderator

    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
     
  8. ztk.me

    ztk.me ISPConfig Developer ISPConfig Developer

    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.
     
  9. ztk.me

    ztk.me ISPConfig Developer ISPConfig Developer

    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 :D
     

Share This Page