Stopped (ctrl z) process will not restart, and no longer in job list

job-control

I was running apt upgrade, when I needed the terminal, so did a ctrlz. When I tried to restart it (fg), it would not restart, because it was no-longer in the jobs list (jobs). (I Did not, run disown). I then did a ps to get process id. It showed the process to be stopped (as expected), so I then did sudo kill -s SIGCONT pid, to re-start it, but nothing happened. ps showed that process was still stopped. There was no error message.

What I did.

sudo apt upgrade
«wait a bit»
«ctrl-z»
«some other command» #can't remember, but nothing special.
fg #This command failed, no such job
jobs #No output

What I tried to fix it.

  • send sigcont to apt
  • send sigcont to sudo

  • What happened for the shell to disown the process?

  • (more importantly) How do I re-start it?

Output from ps -l -p $(pgrep apt)

F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 T     0 22884 22883  0  80   0 - 21617 -      pts/1    00:00:01 apt

Output from pstree -s -p $(pgrep apt)

systemd(1)───kdeinit5(1038)───ksmserver(1062)───yakuake(1153)───bash(1225)───sudo(22883)───apt(22884)

Output from pgrep bash | xargs -n1 ps -l -p

F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S  1000  1225  1153  0  80   0 -  8770 core_s pts/1    00:00:00 bash
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S  1000  3852  3849  0  80   0 -  8404 -      pts/7    00:00:00 bash
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S  1000  4449  4445  0  80   0 -  8392 core_s pts/3    00:00:01 bash
⋮

Ideas: has it lost contact with stdout/stdin?, does it need it?


System Debian, bash

#↳ bash --version
GNU bash, version 4.3.30(1)-release (x86_64-pc-linux-gnu)

#↳ uname -a
Linux delorenzi 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux

#↳ sudo --version
Sudo version 1.8.10p3
Sudoers policy plugin version 1.8.10p3
Sudoers file grammar version 43
Sudoers I/O plugin version 1.8.10p3

Best Answer

The usual culprit to suspect would be an honest confusion. The most obvious place to check is that you are running jobs from a shell whose PID matches the expected one (1225). In the comments you mention that you have the terminal, but I am suspecting the "some other command" may have started another shell? Did you confirm the $$ of the shell you are running jobs from?

Related Question