12

I typed suspend in my terminal, and it suspended the execution.

How do I get back to normal terminal functioning? I've tried Ctrl+C, Ctrl+D, Ctrl+Q (as suggested here), and Ctrl+Z, but none of these work. Of course I can close the terminal and open a new one, but is there no way to "resume" the terminal functionality?

I'm running Ubuntu GNOME 16.04, with default (bash) shell.

200_success
  • 1,239
  • 11
  • 21
Cerberus
  • 353
  • 1
  • 3
  • 9

1 Answers1

13

From your link:

until it receives a SIGCONT signal.

So that would be kill -SIGCONT {pid}

  • killall -CONT bash would resume all.
  • kill -18 {pid} would be the same.
  • and so is kill -s CONT {pid}

According to this list it should be control-z but you need to use control-z to stop the process:

18 - SIGCONT - Resume process, ctrl-Z (2nd)
19 - SIGSTOP - Pause the process / free command line, ctrl-Z (1st)

You need the {pid} of the shell session running in the terminal

And there is also job control commands: 

fg, bg

The fg command switches a job running in the background into the foreground. 
The bg command restarts a suspended job, and runs it in the background. 
If no job number is specified, then the fg or bg command acts 
upon the currently running job.
Rinzwind
  • 293,910
  • 41
  • 570
  • 710
  • It should also be Ctrl+Q, but that isn't working for some reason. I assume because since the shell is suspended, it can't receive the Ctrl+Q (SIGCONT) from the suspended session. It does work if, as you say, you use `kill -SIGCONT PID` but I can't find a simple way of getting the suspended session's PID when I have many terminals open. – terdon Sep 12 '17 at 13:25
  • This isn't working. I used ps aux | grep term to get the pid of the the terminal, tried all 3 variations of SIGCONT but none worked. When I did just kill pid the terminal did close, so I did have the correct pid. – Cerberus Sep 12 '17 at 13:25
  • @Cerberus you want the PID of the shell session running in the terminal, not of the terminal itself. If you only have one open terminal, it should be easy to find with `pgrep bash`. If not, use `pstree -p`, find the terminal's PID there and look at the PIDs of its children, one of which should be your bash session. – terdon Sep 12 '17 at 13:26
  • I will need to have two terminal sessions at least in the scenario, one which is suspended and the other from which to send SIGCONT. – Cerberus Sep 12 '17 at 13:26
  • Well yes. If you want to use suspend. Can't really think of why you would want to though. – terdon Sep 12 '17 at 13:27
  • @Cerberus yes you need 2 :-) – Rinzwind Sep 12 '17 at 13:28
  • I was just wondering how to get back. But thanks, this finally worked. Using pgrep bash and trial and error to identify correct shell session worked out for me. – Cerberus Sep 12 '17 at 13:28
  • 1
    SIGCONT is normally ignored, so why not just fire ``killall -CONT bash``? :-) – Jonas Schäfer Sep 12 '17 at 14:45
  • @JonasWielicki nice, this is a lot easier and resumes all suspended shell sessions. – Cerberus Sep 12 '17 at 16:58
  • I assumed one pid though and not all. edit: added it :) – Rinzwind Sep 12 '17 at 17:14