To avoid a process to stop when exiting the shell, you can launch the command via nohup or screen. It is also possible to disown an existing process with following commands:

mycommand
# Press CTRL-Z
bg
disown %1

But this can be launched only from current shell.

I'd like to do the same thing using another shell/ssh session (command launched on shell A, but disown launched on shell B).

Putting the process in background from another shell is possible:

# CTRL-Z can be done via
kill -20 PID (SIGSTP)
# bg can be done via
kill -18 PID (SIGCONT)

But the process is still owned by the initial shell. How do I disown the process from another shell?

I'm using Linux 4.15

This is not possible.

Well, it is if you are prepared to muck around with a debugger, and poke the internals of the process running your shell program. So more specifically: this is not possible in a simple straightforward manner at the level of shell programming.

This is because disown affects a list of "jobs" that the shell program maintains in the memory space of each individual shell process.

Shells (job control ones, that is) remember the child processes that they forked in their internal "job tables", until they are instructed to forget about them by disown or the child processes terminate and the shell has wait()ed for them and reported the termination of the "job". disown does not affect the child process state in any way. It affects what the shell does.

Because it forgets about the disowned process …

• … it no longer recognizes the completion of a "job" when wait() informs it about the termination of the child;


• … it no longer cares if the process is still running when it is told to exit/logout; and


• … it no longer sends a hangup signal to the child when it receives a hangup signal itself (or, in the case of some shell programs, when it exits and it knows that it is an interactive login shell).

Shells do not share these lists, and they are not easily accessible (sans, as mentioned, firing up a debugger and attaching it) from other processes. There is no IPC mechanism or command-line tool for accessing them except for the built-in disown command run within the relevant shell process itself. (This is why it is a built-in command.)

This is why you cannot even disown jobs from a second shell even within the same login session. disown is entirely a per-shell per-shell-process thing.

Furthermore …

Putting the process in background from another shell is possible.

Actually, that is not what you've been doing.

The notion of foreground and background are relative to the controlling terminal of the session. Specifically, there is one process group, known to the controlling terminal, that is the foreground process group. Stopping and continuing processes does not by itself switch processes between foreground and background. One needs to update the controlling terminal's foreground process group as well. A foreground process is only in the foreground by dint of being a member of that foreground process group. All other process groups in that session, and thus processes in those process groups, are in the background.

Ironically, you haven't been doing this from another shell. What you've been doing is triggering the original shell process to take action. It sees the main process of the foreground process group stop, and it adjusts the terminal's foreground process group (back to its own process group) in response.

The right signal is SIGTSTP, by the way.

Further reading

• In zsh, how can I more quickly disown the foreground process?


• Is it possible to add a process to the job list in bash (e.g. to reverse "disown")?

If you are on Solaris, you may call:

nohup -p <pid>

This removes the current controlling terminal and connects stdout to a file in the filesystem.

To be able to do this, you need to have support from the kernel (in this case the /proc filesystem). Support to the nohup program has been added to Solaris in 2001. If other platforms are able to attach debuggers to running processes from other terminals, this feature could be added.

BTW: If you look at the shell that was running the process before, you may see a "no children" error message from the wait() call in the shell.

I am currently not aware of similar constructs on other platforms.