3

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

daaawx
  • 105
Golgot
  • 141
  • 1
  • 1
  • 6
  • See https://unix.stackexchange.com/a/452267/117549 – Jeff Schaller Aug 01 '18 at 13:23
  • @JeffSchaller : it is indeed the same issue (from a distinct perspective). Unfortunately I can't change the code of the process. – Golgot Aug 01 '18 at 14:12
  • If you hadn't twice erroneously conflated terminal and shell in the question, people would likely not be conflating disown and nohup in answers. disowning is a shell notion, not a terminal one. https://unix.stackexchange.com/questions/3886/ https://unix.stackexchange.com/questions/4126/ – JdeBP Aug 01 '18 at 14:24
  • @JdeBP, You are right, I changed terminology to shell... – Golgot Aug 01 '18 at 14:33
  • You might also look at reptyr which tries to move a process to a new pty (eg terminal). – meuh Aug 01 '18 at 16:03

2 Answers2

4

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

JdeBP
  • 68,745
1

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.

schily
  • 19,173
  • Thank you for your reply, unfortunately I'm not on Solaris but it may help other people... – Golgot Aug 01 '18 at 14:10
  • This is conflating nohup and disown. The questioner is asking about the latter. – JdeBP Aug 01 '18 at 14:20
  • And since nohup does what the questioner was asking for, I created this answer. It should be obvious that disown cannot do what the questioner likes to do, as disown just removes a job from the job table of a shell but does not have any influence on the job itself. – schily Aug 01 '18 at 14:35
  • nohup was not what the questioner was asking for. This is pretty clear in the question, where it talks about jobs being killed by a shell when it exits, explicitly uses disown, explicitly distinguishes what it is talking about from nohup, and requests to perform the same thing as disown from outwith the shell. – JdeBP Aug 01 '18 at 14:52
  • Reread the question: this was on how to detach the controlling tty and this can only be done via nohup. – schily Aug 01 '18 at 14:54
  • Take your own advice. There is no mention of controlling terminals anywhere in the question. But disown gets mentioned three times, once in the title. – JdeBP Aug 01 '18 at 14:55
  • Well, I read what he most likely wants is to cut off the connection to the controlling tty, since disown is de-facto a noop. – schily Aug 01 '18 at 15:22
  • OK... I have to admit that i'm not familiar at all terminology and I may use wrong terms which can make my question hard to answer. Basically, the current scenario is : open one terminal in ubuntu, launch a command which will not end. Now I want to make the command continue without touching the first terminal. – Golgot Aug 01 '18 at 15:50
  • The real use-case scenario is almost the same but remotely (program launched from a ssh session), now I want to make sure the program continue even if the connected computer disconnect (I don't have access to the computer) – Golgot Aug 01 '18 at 15:55
  • So this is where the nohup -p pid method would work. – schily Aug 01 '18 at 16:04
  • Thanks for taking the time to suggest a partial solution. – Rolf Sep 29 '23 at 18:42