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.
&>>
is a bashism: to a POSIX shell (such as/bin/sh
- the default shell used bycron
) it means "run the command in the background and append nothing to ..."sh
s everywhere - which will override any shebang lines like#!/bin/bash
(definitely a problem for those&>>
redirections)path/to/the.sh