Score:2

Ubuntu

Command dependent on background job finishing

Marc

3/21/24, 3:43 AM

I am trying to run a background-job that should send an email after it terminates. The background-job can run several hours and should run independent of the Shell it was started in (because SSH will disconnect). In my current script below the mail command does not wait for the BACKGROUNDJOB to terminate. How can I achieve this?

nohup BACKGROUNDJOB -l $corefolder/$filename >/dev/nul 2> $corefolder/$filenameerr &
mail -s "JOB DONE" -A $corefolder/$filename -A $corefolder/$filenameerr abc123@gmail.com <<< "job finished on $HOSTENAME on $(date)"

The mail should attach 2 output files from the BACKGROUNDJOB, which are only available after it has terminated.

Or generally:
#Script.sh
Process 1 (e.g. run rsync) [this could take 10h and only then rsync.log is available]
Process 2 (send email with rsync.log as attachment)
#end script

AND the entire script should put itself in the background to run independent of the shell and continue running even when ssh disconnects.

392

1 + 5

command-line

bash

scripts

job-control

background

waltinator

3/21/24, 5:13 AM

Write a simple bash script to invoke your `BACKGROUND JOB`, `wait` (see `man $SHELL` about "Job Control"), then send the mail. `nohup` that script.

Marc

3/21/24, 6:26 AM

thats what my script above is showing but the mail is sent before the first part ends.

waltinator

3/21/24, 6:40 AM

Don't put `BACKGROUND_JOB` in the background (remove trailing `&`) and `nohup the_script &`. Put the whole script in the background as a simgle blob

Marc

3/21/24, 8:05 AM

Calling the script as "nohup script.sh" is not ideal as the script will be used by others who should just be able to execute as "script.sh" (without having to consider whats happening in the foreground/background etc). There must be a way to execute wihtin a script 2 processes in the background while 2nd is dependent on the 1st and is waiting in the background.

muru

3/21/24, 8:13 AM

@Marc you could have an optional argument in the script that, if set, causes the mail to be sent.

Score:4

Ubuntu

Raffa

3/21/24, 9:28 AM

... and should run independent of the Shell it was started in

It can't run independent of the Shell it was started in ... It needs the shell to interpret its commands all the way through until its end/exit.

(because SSH will disconnect)

Disconnecting SSH will result in disconnecting the user's terminal which will in turn result in a SIGHUP(hang-up) signal and the latter will cause the shell to terminate as the shell is merely a child process of the parent user's terminal ... In bash, you can tell your shell to ignore the SIGHUB signal with the job control builtin disown

In my current script below the mail command does not wait for the BACKGROUNDJOB to terminate. How can I achieve this?

If you nest the commands in order e.g. comman1; command2; ... without sending any preceding commands to the background like e.g. so:

BACKGROUNDJOB -l $corefolder/$filename >/dev/nul 2> $corefolder/$filenameerr; mail -s "JOB DONE" -A $corefolder/$filename -A $corefolder/$filenameerr abc123@gmail.com <<< "job finished on $HOSTENAME on $(date)"

Then the latter command will wait for the former command to complete execution first.

the entire script should put itself in the background to run independent of the "shell"(you mean parent terminal) and continue running even when ssh disconnects.

You can achieve this like so (the sub-shell syntax (...) might not be always needed here but doesn't harm to use in all cases):

(/path/to/scriptfile) & disown

Or if you like to nest the commands in order instead, like so (the sub-shell syntax (...) is needed here):

(BACKGROUNDJOB -l $corefolder/$filename >/dev/nul 2> $corefolder/$filenameerr; mail -s "JOB DONE" -A $corefolder/$filename -A $corefolder/$filenameerr abc123@gmail.com <<< "job finished on $HOSTENAME on $(date)") & disown

+ 1

Marc

3/21/24, 10:26 AM

Raffa. Awesome. Your last line is the solution to my problem. Many thanks for this one-liner!!!

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Command dependent on background job finishing

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.