Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wish to fetch content from a PHP script on my server two times a day, altering a query variable lang to set what language we want, and save this content in two language specific files. This is my crontab:

*/15 * * * * ~root/ > /var/log/checkapache.log
10 0 * * * wget -O /path/to/file-sv.sql ""
11 0 * * * wget -O /path/to/file-en.sql ""

The problem is that only the first wget command line is being executed (or to be precise: the only file that is being written is /path/to/file-sv.sql). If I switch the second and the third row, /path/to/file-en.sql gets written instead. The first line always runs as expected, no matter where it is.

I then tried using lynx -dump "" > /path/to/file-xx.sql to no avail; still only the first lynx line executed successfully. Even mixing wget and lynx did not change this!

Getting kinda desperate! Am I missing something? There are thousands of articles on crontab (combined with) wget or lynx, but all seems to cover basic setups and syntax. Does anyone got a clue of what I am doing wrong?


share|improve this question
Are you sure that whenever you access something is returned ? have you tried this from a command line to see what happens (wget -O - ? – Torian Feb 2 '11 at 21:17
I would try erasing and recreating the carriage return between 2 and 3. – Antonius Bloch Feb 2 '11 at 21:24
Best practice is to specify the full path to the executables in crontab. Like: "/usr/bin/wget". I don't think this would help in your case, since one of the crons works. – Antonius Bloch Feb 2 '11 at 21:26
What is displayed in cron's log when this happens? – beans Feb 2 '11 at 21:26
@Torian: Works like a charm. – Alexander Wallin Feb 2 '11 at 21:31
up vote 28 down vote accepted

Try adding newline at the end of your crontab.

share|improve this answer
You're a godsend! That did it! I'd vote you up if I had the reputation. :) – Alexander Wallin Feb 2 '11 at 22:48

There's something about the text that's wrong. Edit your crontab in vim then show invisible characters.

:set invlist

You should be able to see and then correct it.

share|improve this answer
Wrong how? How do I edit it in Vim? I tried rewriting the whole file in the case that copy-pasting would cause problems. – Alexander Wallin Feb 2 '11 at 21:55
@afEkenholm: how do you edit it now? – bahamat Feb 2 '11 at 22:12
@bahamat: # crontab -e – Alexander Wallin Feb 2 '11 at 22:13
@afEkenholm: do this: EDITOR=vim crontab -e – bahamat Feb 2 '11 at 22:14
@bahamat: Everything looks just fine. Got a purple $ at the end of each line? – Alexander Wallin Feb 2 '11 at 22:17

Try add redirect, to debug crontab(or read root mail):

11 0 * * * wget -O /path/to/file-en.sql "" > /tmp/crontab_ouptput 2> /tmp/crontab_error

Also run 'wget -O /path/to/file-en.sql ""' from console.

Also use 'crontab -e' for validation new crontab.

Also, try delete not working line and retype it from keyboard.

Backup corntab and run command:

crontab -l | crontab -
share|improve this answer
Adding /tmp/crontab_ouptput 2> /tmp/crontab_error only works for the first line. Running the command from the console works just fine. Rewrote the whole file with my bare hands, but nothing changed. – Alexander Wallin Feb 2 '11 at 22:01
Backup crontab and try: crontab -l | crontab - – alvosu Feb 2 '11 at 22:23
Thanks for the efforts, @alvosu, but a simple newline did the trick! – Alexander Wallin Feb 2 '11 at 22:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.