Issues with Background Process Handling in Bash Script

Shell Programming and Scripting
1

I'm currently working on a Bash script to automate a few tasks on a CentOS server. The script runs multiple commands in the background using &, and I'm using wait to ensure they complete before continuing.

However, I'm running into inconsistent behavior—sometimes the script exits prematurely or skips the final steps. Here's a simplified version of what I'm doing:

#!/bin/bash

./task1.sh &
./task2.sh &
wait

echo "All tasks completed. Proceeding..."


echo "All tasks completed. Proceeding..."

Any idea why this might minecraft apk happen? Could it be related to how subprocesses or PIDs are being handled? Would using trap or checking $! improve reliability here?

Thanks in advance for any guidance!

2

$! deals with the job control just like wait.

I think it receives a signal. Try trap to capture some kill signals.

trap "" HUP INT TERM
1 Like
3

Yes, and ChatGPT 4o agrees with MIG and adds some details:

Your current script logic is mostly fine, but here's the tight diagnosis:

What can go wrong?

  1. task1.sh or task2.sh may fail immediately, exiting with an error, but wait doesn’t propagate failures—it only waits.
  2. Script appears to "exit prematurely" if one background job exits fast and the other hangs or dies silently.
  3. Redundant echo line suggests copy/paste error or confusion in script testing.

Minimal fixes

If all you care about is reliably waiting for both to finish:

#!/bin/bash

./task1.sh &
pid1=$!

./task2.sh &
pid2=$!

wait $pid1
status1=$?

wait $pid2
status2=$?

if [[ $status1 -ne 0 || $status2 -ne 0 ]]; then
  echo "One or more tasks failed." >&2
  exit 1
fi

echo "All tasks completed successfully. Proceeding..."

Why this works better

  • Captures and checks return codes from both background jobs.
  • Avoids ambiguity if one task crashes early.
  • wait without arguments waits for all background jobs, but doesn’t tell you which one failed or why.

Using trap?

Only if you need to:

  • Clean up on Ctrl+C (SIGINT) or exit.
  • Avoid zombie processes or clean temp files.

Example:

trap 'echo "Aborted. Killing jobs..."; kill 0; exit 1' SIGINT

This kills all subprocesses on Ctrl+C.

Bottom line: capture PIDs and check exit codes directly. That gives you robust control without extra complexity.

4

Not my area, but I have seen comments elsewhere like:

"Bash aggressively marks dead jobs, and takes them out of the job list".

That is, if Bash sees a job end (maybe through a SigChld), it keeps the exit code, but it does not need to actually wait for that job when you invoke "wait".

One reference is Re: wait -n misses signaled subprocess, but it may not be the best.

3 Likes