cron is broken (debian)

i noticed recently that cron has totally stopped since i moved to a new server.

when i visit the urls for cron, the cron events are triggered correctly (e.g. www.mysite.com/cron/monthly). so the issue is the way cron is functioning within the server, rather than elgg.

i have read many pages now about cron and still not located the issue. the cron logs show that the events are being triggered.
the only possible cause i am seeing in the logs is that the logs are outputting:

 CMD ($GET ${ELGG}cron/hourly/)

so they are not repacing the $ variables with the actual paths that the variable represent. i'm not clear on whether that is the cause of the problem here or not.

i've checked that the GET variable is pointing to a valid WGET binary - and it is.
i've added a blank line at the end of the crontab file, as was advised in a forum page i found for debuging cron.

i've restarted the cron service several times.

i've added some text to the end of one of the cron items, to output debug info for the event to the cron log:
 2>&1 >>/var/log/cron.log

which didn't work..

so i'm wondering if anyone here has any experience to add as to why this is broken?
thanks

  • Is it a users crontab (in home directory) or have you added the cronjobs to the system-wide crontab? In case of the latter you would need to add the user account the job should be running under as second parametet, i.e.

    <when> <username> <command>

    It could also be that the syntax for defining variables (defining a string) within crontab is different on the new server. You could try (at least for one cronjob) to not use variables but writing the whole line without using the $GET and $ELGG variables. Maybe it works then.

  • thanks for the tips. :)
    i discovered that when i run the same wget command from a command line i am seeing 403 - permission denied..
    so i looked in the server config and saw a line to block wget - which would have produced a 403.
    so i removed that line, thinking i had solved the problem.. and ran wget again, only to find the same 403 error!
    i then thought that the problem might be that wget needs to be configured for ssl, since my site is https only.. i added --secure-protocol=auto and also some other settings..
    however, that made no change either..
    i continue!

  • aha. i added -U Mozilla to the wget string.. and now the 403 issue is resolved..
    though the cron is still not being shown as being triggered in elgg.

  • i found that indeed, for some reason, the default elgg method of using variables in the crontab was not working.. i replaced the variables with the paths manually and now they are working ok.

  • wget --no-check-certificate

  • i already got this to function. i am unclear on why you are syaing that no-check-certificate would be an improvement  here..

    according to this page: https://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-Options.html

    that option will only be relevant where there is a glitch with the server certificate. in my case, the certificate is (as far as i am aware, fine) and is working ok when i change the user agent to mozilla.
    maybe there is some other part of my server config that is set to block wget.. though i don't know where.

  • Sorry for posting without explanation. Also, I only noticed that you already got it working now (not noticing your second to last posting before).

    The --no-check-certificate option could have helped if you wouldn't have already got it working. The problem could have been the wget version on your server having been compiled without proper support of handling certificates (or the necessary packages to handle certificates might have been missing on your server). The --no-check-certificate wouldn't have hurt much in my opinion as you use wget from your server (cron) to call an url on your server.

    String handling / assigning is depending on the shell used on the server. Therefore, the Elgg cron example won't necessarily work on any server.

  • no probs.
    from what i have seen, the standard approach to crontab variable syntax should be ok with debian.. though apparently not for me presently.