0

Have a problem with screen where I can detach and attach a given screen session with a bunch of processes in it but there's nothing visible when reattached. I have an emacs session running in this screen with a bunch of R processes running in it. Unfortunately, I have another emacs session & R processes running elsewhere and really can't risk terminating or signaling either emacs session or the R processes. (They're running a long process and I really don't need the hassle of running it from the start again).

I was hoping someone might be able to help me identify the following

  1. Which processes were started from within the screen session

  2. Which process broke everything.

  3. How I can signal or interrupt that process.

Thanks.

Sidenote: I know I can just kill the screen session outright and the right processes will fall out. I just have some really important stuff in that session I'd really rather not lose.

pynexj
  • 19,215
  • 5
  • 38
  • 56
Andre Forbes
  • 1
  • 1
  • Occasionally you can differentiate based on memory use and/or processor usage, both available with `top`. – r2evans Feb 28 '17 at 21:21
  • First thing I looked into... the problem is, those other R session look pretty innocuous. If I could get when the process was started that would really help though. – Andre Forbes Feb 28 '17 at 21:24
  • `ps fax` (or `ps aux`) will show you the `TTY` for a specific process. If you look at the whole tree of processes, you might be able to infer which is the one you need. Using this, go to the *good* emacs/R session, run something like `system("sleep 10")` and look for it in the process list ... and kill the *other* one. – r2evans Feb 28 '17 at 21:41

1 Answers1

1

Try pstree -p or ps axf and you'll get the process hierarchy.

pynexj
  • 19,215
  • 5
  • 38
  • 56