Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#693 closed Bug/Something is broken (fixed)

My cron job for kyjustice not working

Reported by: alfredo Owned by: cron, Drupal
Priority: High Component: Tech
Keywords: cron mandela.mayfirst.org Cc:
Sensitive: no

Description

I know I did something absolutely obvious but my cron job for kyjustice which is on mandela isn't running at all. I've tried to change it a bunch of time and currently have it set to run every 10 minutes (at least I think I do) but it's not calling cron.php every ten minutes. At least there's no index update. Up to now, no big problem but we're now inputting the whole library so...this needs to be working.

Can somebody take a look in mandela? I'm sure what I'm doing wrong is obvious. :(

Change History (15)

comment:1 Changed 11 years ago by Jamie McClelland

Resolution: fixed
Status: newclosed

It looks like curl was not installed on mandela. Your cron job looks like it was properly setup - but since it relies on curl, it was not properly executing. Often I copy and paste the command line in a cron job to try to debug.

I installed curl and tried copying and pasting the curl line and it seems to be working now, so I'm going to close this ticket. I also added curl to the default list of packages to install on new shared servers.

comment:2 Changed 11 years ago by alfredo

thanks

comment:3 Changed 11 years ago by Daniel Kahn Gillmor

Keywords: cron mandela.mayfirst.org added

A good technique for debugging cron jobs is to try to run the specific command as the intended user by hand.

So if your crontab looks like:

0 foo@bar:~$ crontab -l
# m h  dom mon dow   command
*/10 * * * * testprog http://blah.example.org/cron.php

0 foo@bar:~$ 

You might try just running the command as the user in question first:

0 foo@bar:~$ testprog http://blah.example.org/cron.php
-bash: testprog: command not found
127 foo@bar:~$

if it fails from the shell, you can at least get clearer, more immediate error messages that might give a hint of what the problem is.

comment:4 Changed 11 years ago by alfredo

Thanks, Daniel. What's testprog? And should we keep talking while this ticket's closed?

comment:5 Changed 11 years ago by Jamie McClelland

Yes - I think talking while the ticket is closed is perfectly fine - the conversation remains on the site even if the immediate issue is over. If a new issue comes up - then a new ticket is inline, but I think of this conversation as good extra stuff for the original ticket.

In dkg's example, testprog is just a random example he is using (and in his example, it shows that "testprog" is not actually installed. In your example, the program in question was "curl":

0 kyjustice@mandela:/home/jm$ crontab -l
# m h  dom mon dow   command
10 * * * *  /usr/bin/curl curl --silent --compressed http://kyjustice.mayfirst.org/cron.php

0 kyjustice@mandela:/home/jm$

comment:6 Changed 11 years ago by Daniel Kahn Gillmor

jamie, in your example, the job will run every hour at 10 minutes past the hour. In alfredo's original post, he specified that the job was intended to run every 10 minutes. I dunno how important that difference is for the site in question, but i thought it was worth noting for the syntactic difference.

comment:7 Changed 11 years ago by Jamie McClelland

Thanks for pointing that out dkg - I think running every 10 minutes is excessive - is once an hour at 10 minutes past the hour ok with you Alfredo?

comment:8 Changed 11 years ago by alfredo

Cron jobs should run every ten minutes (actually, I think five minutes is better) while we're moving data and developing the search engine. After that, I'll change it to hourly. This is very very important for testing pdf searching, etc. on both ky and mass sites. That's why I set it that way. Thanks for asking. :-)

comment:9 Changed 11 years ago by Jamie McClelland

It's currently set to run once an hour at 10 minutes after the hour:

0 kyjustice@mandela:/home/jm$ crontab -l
# m h  dom mon dow   command
10 * * * *  /usr/bin/curl curl --silent --compressed http://kyjustice.mayfirst.org/cron.php

0 kyjustice@mandela:/home/jm$

If you want it to run every 10 minutes, you can change the first "10" to "*/10". You can edit it with:

sudo su kyjustice
crontab -e

Don't forget to change it back when development is over :).

comment:10 Changed 11 years ago by Daniel Kahn Gillmor

If you want to test searching and other things that might only be triggered by the cron job during your development, another technique you can use is to trigger the drupal cron.php processing manually.

You can do this from any 'net-connected machine just by hitting the page:

curl http://kyjustice.mayfirst.org/cron.php

(i personally prefer wget to curl, probably because it's part of debian by default, so i'd use:

wget -q -O- http://kyjustice.mayfirst.org/cron.php >/dev/null

but either one will work fine)

comment:11 in reply to:  9 Changed 11 years ago by Daniel Kahn Gillmor

Replying to https://id.mayfirst.org/jamie:

You can edit [a user's crontab] with: ...

This can be done more simply with:

sudo -u kyjustice crontab -e

comment:12 Changed 11 years ago by Daniel Kahn Gillmor

Also, i notice that the cronjob itself is probably not quite right:

/usr/bin/curl curl --silent --compressed http://kyjustice.mayfirst.org/cron.php

tries to download two URLS:

  • http://kyjustice.mayfirst.org/cron.php, and
  • curl (which isn't a URL, which causes a failure for that part of the cronjob).

try running it by hand without the --silent argument to see the failure.

The failed download probably isn't a terrible thing, but it's unclear what it is supposed to do, might get copied into other places, and could potentially cause trouble in the future.

comment:13 Changed 11 years ago by Jamie McClelland

Thanks for the correction Daniel - I just fixed it on the cron job page.

Also - I have no love for curl - I just changed the cron job page to use wget.

comment:14 Changed 11 years ago by Daniel Kahn Gillmor

The changed cron_job uses wget, but dumps to stdout (-O-). This will result in a noisy cronjob (mail will be generated) if the page itself has any content. Any reason not to add >/dev/null at the end?

comment:15 Changed 11 years ago by Jamie McClelland

Woops - I missed that part - just added it now.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.