7

If I disown a job in bash and change my mind, can I undo it somehow ?

If so, taking it further, is it possible to bring an arbitrary process under job control (an acceptable restriction would be that I own the process) ?

And, finally, would this make the below workflow possible:

  • put job in background (^z followed by bg)
  • get its pid (jobs -p %+ to get its <pid>)
  • open a screen or tmux session, attach to it and use it for the following steps
  • use reptyr to grab the job (reptyr <pid>)
  • add <pid> to shell's job control (is this possible at all?)
  • stop the job (^Z)

I can do everything except the last two steps. Stopping the job with ^Z doesn't work because the process isn't in the shell's job list.

My research indicates that it isn't possible to own (reverse of disown) a pid but hopefully I am wrong...

Lesmana
  • 27,439
starfry
  • 7,442
  • 2
    You cannot own the job, but if your goal is to stop the job then you can send it a SIGSTOP signal via kill command. – jimmij Jul 13 '15 at 09:56
  • The spec says: Using bg to place a job into the background shall cause its process ID to become "known in the current shell execution environment", as if it had been started as an asynchronous list; see Asynchronous Lists. But, anyway, if you're going this far, and since you seem to be primarily linux focused, you should probably just be working w/ namespaces. – mikeserv Jul 13 '15 at 10:01
  • Fwiw I agree with jimmij. I think you are over thinking this a bit. – Bratchley Jul 13 '15 at 23:09
  • @Bratchley not sure how you can say I am overthinking anything. It isn't about being able to stop a job at all. It's about being able to make a process "known in the current shell execution environment" as @mikeserv says; it's about wanting to fill a hole in one's knowledge. It's about confirming my belief, as @jimmij concurs, that it is not possible. Being able to do ^Z was just an example of something that isn't possible without it being owned by the shell. I don't think your comment adds any value to the question. – starfry Jul 14 '15 at 08:03
  • There was nothing in the question that implied this was purely academic. It's kind of a silly thing to worry about not being able to do anyways. – Bratchley Jul 14 '15 at 13:55
  • reptyr -T will steal a terminal emulator's master fd and open its own session for it. If your process and the shell process which accompanies it are associated with the same master fd - even if you have previously disowned the process you're talking about - then you may be able to reassociate the two in the new reptyr session. – mikeserv Jul 14 '15 at 19:51

1 Answers1

3

In general, it isn't possible for a shell to “adopt” a job. For a shell, a job means a few things:

  • Associate a job identifier with a process ID.
  • Display its status (running, suspended, dead).
  • Notify the user when the status changes.
  • Send a SIGHUP signal when the terminal goes away.
  • Control whether the job “owns” the terminal (whether it's the foreground process group).

Most of these don't require any special association between the shell and the job, but there are a few that do:

  • In order to notify the user when the status changes, the shell relies on receiving a SIGCLD signal. This signal is sent by the kernel to the parent process of the job's initial process.
  • In order to control access to the terminal, the shell needs to be in the same session as the job.

It isn't possible for a process to adopt another process, nor to attach a process to an existing session. So in order to support adoption, the shell would have to manage a partial status. The usual shells haven't implemented this.

In the special case where the job is one that was initially started by that shell and then disowned, these problems do not arise. But none of the usual shells have implemented an exception to the exception that lets them add a job if they had initially started it.

In your scenario, it would usually be most convenient to start the job in a screen or tmux session, and to use the PID if you want to suspend or resume it.

Gilles 'SO- stop being evil'
  • 829,060