I want to terminate an instance of GNU screen whilst preserving the process running inside it.

So I opened my regular terminal emulator program and executed screen. Then I used that instance of screen to execute ./script_x.sh. Now, for whatever reason, I want to quit using screen however script_x.sh hasn't yet completed its task and I'm not willing to forfeit my progress.

Can I keep the active process alive so as to continue working on it inside my regular terminal emulator?

  • 14
    Do you really want to kill screen or do you want to detach from it? Screen is meant to be used for running a process in the background so that you can continue in your normal session, it also allows apps to keep running after you logout (e.g. disconnect your SSH session). You can always detach from screen, continue in your normal session and pickup where you've left in the screen session. Your terminal emulator has nothing to do with this.
    – BlueCacti
    Mar 18, 2016 at 10:23
  • Or just create another screen inside the screen session. Mar 18, 2016 at 12:18
  • 11
    This questions smells like the XY Problem. Mar 18, 2016 at 15:23
  • 7
    @tjt263 - you say you regret using screen in the first place, so what would you do to keep your process running if you hadn't used screen? You can still do the same thing with the process in screen, but screen has the added advantage is that you can detach from it and let your process run undisturbed.
    – Johnny
    Mar 18, 2016 at 22:57
  • @DigitalChris It might do now. I feel like the original title was more probably more relevant. There are 3 distinct points: I was running a program inside screen. I wanted to stop using screen. I didn't want to stop the program that was running inside screen. That's it. I don't know how to clarify the situation or express it any simpler than this.
    – voices
    Mar 29, 2016 at 16:40

3 Answers 3


TLDR: Practical answer: No.

Longer answer:

In theory you can. If you started something like nohup myprog & from inside the screen then it will continue running. It will ignore a hangup signal and will not have any input, but in theorie you could continue working with it.

In practise this is not the case. Thus unless you want to attach a debugger to the running process and rewrite its file handles and make sure that the process handles -1 signals when you close screen ... then the answer is no.

If you are ready to do this, I have a bookmark at home pointing to [SU] where someone did just that. Saved for awesomeness, not because it is easy and trivial to do.

  • Note that the question has been edited massively since your answer. Mar 19, 2016 at 9:17
  • Disconnecting a process is fairly straightforward-- it's a question of setting process groups (with disown or at a lower level) so that no SIGHUP will be sent when the parent process is dies. Reconnecting i/o is another thing altogether-- that's where the debugger comes in.
    – alexis
    Mar 19, 2016 at 10:22
  • You don't need nohup if you are in a job control shell (like bash, ksh, csh, zsh, ash, etc.). If you're still using a non-job control shell like Bourne sh maybe it is time to upgrade.
    – chicks
    Mar 21, 2016 at 18:44

You can try using reptyr to reattach already running application to different terminal. It has some issues with sending process to background, though.

I just tested it (start htop inside screen, reptyr it to another terminal, kill screen), and it seemed to work alright. Still it's a really hacky solution, so no guarantees.

  • 1
    Less hacky than using gdb :)
    – Hennes
    Mar 18, 2016 at 10:26

Yes (if "killing" is not really killing), that's actually exactly what screen is for. You should check the manual and try which one of these fits your needs:

C-a d
C-a C-d     (detach)      Detach screen from this terminal.

C-a D D     (pow_detach)  Detach and logout.

Then what you will need is the -D/-d -R/-r command line options of screen, depending on your choice.

  • 1
    This doesn't answer the question. The OP doesn't want to detach from the screen, they want to terminate the screen process. Mar 18, 2016 at 9:59
  • 6
    Yes, he wrote that but I'm not sure he asked what he wanted to.
    – user556625
    Mar 18, 2016 at 10:08
  • 11
    @GuntramBlohm It's not at all clear that the OP understands how screen works, and this is the most likely desired effect. Mar 18, 2016 at 12:18
  • 2
    Are you aware that screen is not a terminal different from xterm but a layer (a pseudo terminal) that can be attached to your real terminal (vterm, xterm, terminator, (m)rxvt, any) after detaching it from any other terminal? And screen is what keeps your process running one you started it inside of screen (and it does it well). If you kill (really kill) screen, then you pull out the rug from under your process... I just don't see any good reason why you would do so.
    – user556625
    Mar 19, 2016 at 9:38
  • 1
    @GombaiSándor: One reason to want to do that would be to make the process talk directly to a terminal in order to pass through capabilities that screen doesn't know about. For example, I once hacked my own version of xterm to make all the weird function keys on my keyboard send escape sequences that included the X11 keysym and the full modifier state, instead of trying to pretend it was a VT102 -- and then started installing keybindings for them in emacs. Those sequences would not pass through screen unharmed. Mar 19, 2016 at 21:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .