I have created a binary file from a Go script, and now I need to run it with crontab. The binary file runs without issues executing it manually from the command line. I am using Ubuntu from WSL. Crontab saves successfully, but it seems the script does not execute.

Cronjob looks like this:

*/1 01 * * * /home/tgr/test-bin/main/main -download > /dev/null 2>&1
  • I was testing this at 1 AM, that is why the crontab hour field is in 01.

Running the script with "-download" flag, tries to download some files from a bucket, using a YAML config file, then makes some secondary tasks like decompression, copying and verifying the structure of the files. It produces a log file too.

I have already started cron service with

sudo service cron start

Could you please advise?

  • Your schedule is just a complicated way of saying * 1 * * *. But the issue is must likely that you haven't started the cron service in WSL. See proposed duplicate.
    – Kusalananda
    May 2 at 7:15
  • Hello @Kusalananda, thanks a lot for your answer. I have already started the cron service, as I have stated in my edited description. Do you have something else in mind that could be causing this behaviour? Thanks for the observation of crontab sintax, btw.
    – TGR
    May 2 at 7:18
  • 1
    To debug, don't discard the output but save it to a file. Is the file created. If so, your job runs. Does the file contain error messages, well, then you have other issues.
    – Kusalananda
    May 2 at 7:31
  • If you temporarily remove > /dev/null 2>&1 you may get more clues in an email to root on that box. I'm assuming it's running as root. If not, does it have permissions to run and read/write all the relevant files as that user? May 2 at 8:19
  • I have tried removing the discard of STDOUT and STDERR, but I don't find some mail or log folder. I am running crontab as my user (tgr) and all the files to read and write are under tgr's home directory.
    – TGR
    May 2 at 15:48

Jobs run through cron, or at, or batch, aren't run in the same runtime environment that you have on your desktop. None of your PATH changes, or other environment variable settings are automatically propagated to your cron job. For example, there's no $DISPLAY, so GUI programs need special treatment (read man xhost).

One can set environment variables for all one's cron jobs in the crontab file Read man 5 crontab.

Look at the results of echo "=== set ===";set;echo "=== env ===";env | sort;echo "=== alias ===";alias in each of your environments.

Since the command part of the crontab line is, by default, interpreted by /bin/sh, which has a simpler syntax than /bin/bash, I recommend having command be a call to a bash script (executable, mounted, starts with #!/bin/bash) which sets up the environment, then calls the desired program.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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