Dropping a job from Bash’s table

 2 min A Bash idiom let an outer subshell finish while a grandchild kept running; it was a narrow SSH workaround, not portable daemonization.

The construction, from a Stack Overflow answer of mine about processes dying when an SSH session closes:

((exec sleep 30)&)

Reading inside out: the inner parentheses open a subshell, exec replaces that subshell with the real command, & makes it asynchronous, and the outer parentheses run the list in a second subshell. Under the Bash/job-control conditions behind the answer, the outer job finishes while the command keeps running as a reparented grandchild. The interactive shell no longer has that command as a live job entry.

That removed one SIGHUP path: Bash could not resend the signal to a job it no longer tracked. It did not make the process immune to hangups. Terminal session membership, the shell’s huponexit behavior, the SSH server, and the exact shell implementation still determine what else receives a signal. The idiom changed the observed Bash job table without changing the command’s own signal disposition.

That is the useful distinction from reflexive nohup. nohup launches the command with SIGHUP ignored; a program that never resets the disposition keeps that choice. The subshell construction does not alter the disposition. It changes parentage and Bash’s bookkeeping, which was enough for the reported case but is a weaker contract.

Over SSH there is a second liveness condition, raised in the comments on that answer: parentage and file-descriptor ownership are separate things. A reparented process still holding a session stream can keep sshd waiting on it, and the connection hangs open after logout even though nothing would signal the process. The historical follow-up redirected stdout:

((exec command)&) >/dev/null

That was enough for the reported case, but stdin and stderr remain inherited. A full standard-stream redirect would be:

((exec command)&) </dev/null >/dev/null 2>&1

or point the outputs somewhere durable. Getting out of the job table changes one possible signal sender; redirecting inherited session streams answers “which session am I still holding open?” The two questions are independent.

I would not use the one-liner as current portability advice. It does not call setsid, reset the working directory or umask, provide supervision, or define how shells other than the observed Bash behave. A service manager is the durable answer. The one-liner instead exposes four different pieces of process state: parentage, job-table membership, signal disposition, and inherited file descriptors.