Why does this bash script terminate the calling process when it ends?

Question

When this bash script is run backgrounded, it terminates the calling shell. Why is this?

#!/bin/bash
#
# weird job control, background termination of parent shell problem
set -eum
echo "Do not go gentle into that good night"
sleep 1

Save this as wat, chmod +x wat, run it as wat - no problem. Run it backgrounded:

wat &

It closes my current shell!? And even more strangely, if that last sleep line is commented out, it can run backgrounded quite happily. Can anyone explain?

I understand that it's to do with the -m (job control) option to set but I don't understand why...

Answer 1

I can see that happen if the script is run with Bash 4.3.30, but not with Bash 4.4.12. (The version of the shell running the script doesn't seem to matter that much.)

I didn't bisect that any further, but there's this in the changelog that looks like it might apply:

This document details the changes between this version, bash-4.4-rc1, and
the previous version, bash-4.4-beta.

i.  Fixed a bug that caused background processes run from non-interactive shells
    with job control enabled to place the terminal in the wrong process group
    under certain circumstances.

Answer 2

From man:

-m Monitor mode.

Job control is enabled. This option is on by default for interactive shells on systems that support it (see JOB CONTROL above). Background processes run in a separate process group and a line containing their exit status is printed upon their completion.

from secure log:

Received disconnect from X.X.X.X: 0

Seems, if we set to -m, the exit status is prints on a current shell after completion of a background process which is exit 0. Able to witness in securelog.