The & backgrounds well except for programs that come back requiring console interaction later on (for example, an "apt -y update &" that eventually enters the STOP state since it's wanting to prompt the user a "really really force?" question much later....when no one is watching anymore).
To plug that hole and inform the process a terminal will really never never become available to it, I append a <&- to some of my commands, completely detaching them from the active terminal telling them STDIN is no longer possible. Make sure /bin/bash is your shell if you use that though. The script will carry on logging any errors related to no pseudoterminal being available on which to cast any prompt.
For example:
`./runme.sh &> runme.log <&- & disown`
is my ultimate way of disassociating from current terminal session. Both STDOUT and STDERR get logged to runme.log, it won't matter if your console or shell terminate sooner or if you logout/su to a different account (no terminal garbage from runme), and thanks to disown even the parent-child PID relationship is removed.
UPDATE: even with that I've had trouble with a semaphore associating it with the name of the original parent, so now I recommend instead:
at now <<< "(cmd1; cmd2; etc.) &> logfile.log"
Of course, remove the &> if you want to get emailed the output from CRON, or redirect it all to /dev/null instead of a file.
screen
) can, among other things, be used to "wrap" longer-running processes. You can detach from it, going back to shell, then reattach and see output from the running process. Reattachment can even be done from another terminal, SSH etc. There may also be other programs that let you do this sort of thing. – poplitea Dec 28 '11 at 7:10