0

I have the following bash script:

clean-tmp.sh

 #!/bin/bash
 tmpreaper 1h /tmp --test > ./tmpreaper.log

When I run it in the terminal using ./clean-tmp.sh, it writes to the file ./tmpreaper.log.

I added the script to the list of cron jobs using crontab -e:

*/5 * * * * cd /home/cron-jobs && ./clean-tmp.sh

I then checked cron's logs and this entry is in there every 5 minutes:

Feb 19 00:45:01 ip-172-31-23-184 CRON[1475]: (ubuntu) CMD (cd /home/cron-jobs && ./clean-tmp.sh)

But it's no longer writing to ./tmpreaper.log.

What on earth am I doing wrong?

codeforester
  • 39,467
  • 16
  • 112
  • 140
Kacy
  • 3,330
  • 4
  • 29
  • 57
  • Are you sure the `cd` is succeeding? This is a place where `exec 2>>/tmp/err.log; set -x; cd /home/cron-jobs && ./clean-tmp.sh` would be useful (or even `bash -x ./clean-tmp.sh`). – Charles Duffy Feb 19 '17 at 01:23
  • Writing to a file using relative path isn't a great programming practice. In general, it is not good for a script to assume that its current working directory is properly set. You may want to take a look at this post: http://stackoverflow.com/questions/41755437/managing-log-files-created-by-cron-jobs – codeforester Feb 19 '17 at 01:25
  • 1
    BTW, the usual cause for this kind of problem is `tmpreaper` not being in cron's PATH. If it's in `/usr/local/bin` for example, that's not there by default. – Charles Duffy Feb 19 '17 at 01:26
  • What happens when you omit the "> ./tmpreaper.log"? You should get a mail with an error message. – mfnalex Feb 19 '17 at 01:29
  • 1
    (As an aside, I'd tend to suggest avoiding `.sh` -- UNIX executables don't generally have extensions; you run `ls`, not `ls.elf`, after all; and `.sh` in particular implies that `sh` is an adequate interpreter to run something, whereas `#!/bin/bash` contradicts that by indicating that bash is its intended interpreter). – Charles Duffy Feb 19 '17 at 01:29
  • @mfnalex, it's only stdout being redirected, so stderr should be getting back to cron regardless. – Charles Duffy Feb 19 '17 at 01:30
  • You could always try `find / -name tmpreaper.log` : it would tell whether the file ends up somewhere unexpected, or is not created at all, which is not a solution but is at least a clue. – Fred Feb 19 '17 at 01:40
  • 1
    @CharlesDuffyI actually had 2 problems, but you were absolutely right. My first problem is that I used an alias in the crontab which you shouldn't do: http://unix.stackexchange.com/questions/1496/why-doesnt-my-bash-script-recognize-aliases. As for the second problem, I had to change my script to use `/usr/sbin/tmpreaper` instead of just `tmpreaper`. I figured out where it was by using `which tmpreaper`. See this link for more info: http://askubuntu.com/questions/47800/command-not-found-when-running-a-script-via-cron Feel free to post an answer. – Kacy Feb 19 '17 at 02:02
  • 1
    For the future, I'd suggest using `type` instead of `which` -- while `which` is an external command that looks through the PATH, `type` is built into the shell and can inspect its internal state, finding what a command would do even if it's *not* in a PATH lookup (identifying aliases, functions, etc). – Charles Duffy Feb 19 '17 at 02:11
  • 1
    BTW, your other option is to put an explicit `PATH` line in your crontab -- any variable assignment you put in the header will be exported to the environment. Thus, `PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin` or such at the top of your crontab will ensure that contents in `/usr/sbin` can be found for all scripts launched by cron. – Charles Duffy Feb 19 '17 at 02:13
  • ...as for a proper answer, feel free to write up your own -- or this might be amenable to close-as-duplicate, as we have quite a lot of questions with the same underlying problem (cron's restrictive default PATH). – Charles Duffy Feb 19 '17 at 02:15

2 Answers2

0

Just specify an absolute path for your file, like tmpreaper 1h /tmp --test > /var/log/tmpreaper.log

mfnalex
  • 833
  • 5
  • 16
  • If the `cd` succeeded, then we know the current working directory with certainty. Unless there's another script called `clean-tmp.sh` somewhere else, then `.` can't possibly be anything other than `/home/cron-jobs` when `./clean-tmp.sh` is successfully invoked. – Charles Duffy Feb 19 '17 at 01:23
  • ...and if it's *not* successfully invoked, then this doesn't fix anything. – Charles Duffy Feb 19 '17 at 01:24
0

@Kacy: Little difficult to say without cron logs, you could have a look to cron logs(/var/log/cron etc).

0,5,10,15,20,25,30,35,40,45,50,55 * * * * cd /home/cron-jobs; ./clean-tmp.sh

May be some systems wouldn't allow time period as the way you tried, try once in above way and let us know then.

RavinderSingh13
  • 130,504
  • 14
  • 57
  • 93
  • 1
    If `*/5` weren't valid, then `crontab -e` would have rejected the edit. Also, the question makes it clear that this is logged as invoked every 5 minutes as it is. – Charles Duffy Feb 19 '17 at 01:25
  • @CharlesDuffy: Thank you for your reply, I am not saying it is not valid, I have seen systems where it allows to save it with crontab -e but it doesn't work so only I suggested if user could try once. – RavinderSingh13 Feb 19 '17 at 01:48
  • 1
    As the OP specified in the question, their syslogs say that cron is actually running the command every 5 minutes. – Charles Duffy Feb 19 '17 at 02:08