1

I have a long-running cron job that I want to run @reboot. I'm calling a bash script that runs two other bash scripts, using crontab -e as root (headless ssh machine). It seems like the second line of the bash script is running, but not the first.

start.sh calls first.sh and second.sh. second.sh seems like it's running, but first.sh doesn't.

I cannot figure out how to find out what is going wrong. I have added an output append &>> to crontab, the bash script that cron calls, and both bash scripts that the first script calls. Everything comes out blank.

I've tried this, this, checked system logs, tried to spy with strace. Everything I look at is blank. All the &>> *.log files are blank, strace returns nothing on the processes that are running, and I can't find first.sh running in any process manager.

ps aux | grep sh doesn't show first.sh to be running.

How can I find out why first.sh isn't being run? It's executable, and works just fine when I'm logged in and call it with terminal, but nothing seems to happen when I call it with cron. Even calling it directly from crontab -e does nothing. Same results.

EDIT: This was marked as a possible duplicate of this question. Though that is helpful information, it did not solve the problem. The same problem persists with absolute paths in cron.

EDIT: Including scripts for syntax errors, as per comment request: crontab -e, ~/startall.sh (When this runs, ~/youtube.sh seems to get skipped, and ~/copy.sh runs), ~/youtube.sh, ~/youtube/run.sh

When I call any of these manually, they work. When I call them from crontab, even directly, they don't work. ~/copy.sh works from crontab, the others don't.

9
  • 2
    It might also be worth noting that &>> is a bashism: to a POSIX shell (such as /bin/sh - the default shell used by cron) it means "run the command in the background and append nothing to ..." Feb 12, 2019 at 20:11
  • I've updated my question the scripts that are involved. Feb 12, 2019 at 20:13
  • 2
    ... I notice you're liberally sprinkling shs everywhere - which will override any shebang lines like #!/bin/bash (definitely a problem for those &>> redirections) Feb 12, 2019 at 20:19
  • 1
    just call the path/to/the.sh Feb 12, 2019 at 20:23
  • 1
    Look at the second answer..It clearly states USE ABSOLUTE PATH IN CRON. Feb 12, 2019 at 20:32

2 Answers 2

4

I can't say why, but unfortunately sometimes some things don't work with @reboot cron jobs (an example for such issue). To prove whether this is the cause of your problem you can create a regular cron job and verify it is executed as it is expected.

If you are experiencing the described issue, you can re-create your script in some way (as it is done in the provided example). Or you can try to execute your script during the startup in some different way, for example through /etc/rc.local or systemd unit.

An ugly idea has come to me - you can try to forward the execution of your script to the at command within the reboot cron job, something such as:

@reboot echo "/path/to/script.sh >> /path/to/the.log 2>&1" | at now

Or add ~1 minute delay:

@reboot echo "/path/to/script.sh >> /path/to/the.log 2>&1" | at now + 1 minutes

It will be cool if it does the job :) In addition:

  • Within crontab, the default vale of the envvar $PATH is /usr/bin:/bin. For all commands/scripts, that are located outside of these directories, you should apply the full path; you can export a new $PATH, before the job; or even you can use $(which my_command) instead of just my_command.

  • You do not need to type sh in front of the name of your script if: it is executable; you are using the full path; and the first line of the file is the shebang #!/bin/sh.

1
  • 1
    Now that I'm getting logs, I can see that I'm getting a permission error. This has solved the problem of not being able to see what is going on. I made a minor correction (awaiting peer review) to your delayed command- man at shows that the syntax is now + 1 minutes instead of now + 1min. Feb 13, 2019 at 16:35
0

Just like steeldriver said, I think the problem is with the sh command. I would edit your scripts to remove the sh commands. So if the script reads cd ~/filename/ && sh ~/filename/run.sh &>> ~/filename.sh.log then remove the sh command after the &&. I would also think it is a good idea to use absolute paths too, but I am pretty sure the issue you are having is with the sh commands in all of your scripts. I opened a terminal and acted as though I wanted to open a program called Leafpad. I typed sh leafpad and got an error, where as if I were to just type the command leafpad without the sh command then it would have started leafpad. By having the sh in front of the command you are trying to execute you are actually running a command with an option that does not exist, or at least that is what I believe is happening.

1
  • If I make a file called test.sh, then run test.sh in terminal, I get an Error: test.sh command not found but if I run sh test.sh, it executes correctly. That's why I have sh all over the place. Running /home/matt/test.sh executes the script without the need for sh. Feb 13, 2019 at 15:58

Not the answer you're looking for? Browse other questions tagged .