I dont think the CTRL+C on the tail is the issue here. I'm betting the job is getting stopped while the tail is running, but you dont see it as bash doesnt tell you such things until right before it shows you a shell prompt (this behavior is default and can be changed with
What I'm thinking is happening is your job is doing something with the TTY. Whenever a backgrounded application tries to read from the TTY, it receives a
SIGTTIN. This is because its in the background, and should not be interacting with the user, and so the
SIGTTIN results in the process being stopped (not killed, stopped). Additionally if you have
stty tostop set and the application tries to write any output to the TTY then it will also be stopped.
Even though you redirect stdin and stdout, it is still possible for applications which have been backgrounded to figure out what TTY theyre on and try to access it directly.
Edit (to answer your comment):
I've had similar issues with a backgrounded ssh as well. I dont know why it tries to access the TTY, but it does, and it gets a SIGTTIN because of it.
You could try wrapping your command in
script -c ./ec2_backup.sh /dev/null &>/dev/null </dev/null &
Script creates a TTY for processes to interact with and redirects this TTY to/from STDIN/STDOUT. Now applications that think theyre interacting with a full TTY, are really only interacting with the simple STDIN and STDOUT pipes. This way you can now redirect STDIN and STOUT to
/dev/null and the backgrounded application wont be able to try and grab the TTY (and get a
SIGTTIN from attempting to do so).