Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm seeing some strange screen behavior on OSX. When I quit screen, child processes are not killed.

$ screen
$ tail -f (or some long running process inside screen)

Then, I kill the current screen window with ^a k or terminate screen entirely with ^a ^\ and it appears everything went well:

$ [screen is terminating]

However, tail -f is still running (with a PPID of 1). Why is it orphaned instead of killed? Is there a setting/flag that alters this behavior? I've tried this under Ubuntu and screen behaves as expected.


share|improve this question

migrated from Jan 26 '12 at 21:39

This question came from our site for system and network administrators.

It works as expected for me under OS X 10.6. Are you running /usr/bin/screen, or some other installed version? – malcolmpdx Jan 26 '12 at 21:42
Yep, /usr/bin/screen and I tried with/without a .screenrc – joepestro Jan 26 '12 at 21:44
Has tail become a zombie or something like that? Theoretically once you close the screen, its tty dies and tail will loose its stdio and just die. If it hasn't died, it might be waiting for some kernel space stuff to be cleared. – Jan 27 '12 at 1:30
That's what I thought too, but tail doesn't go away. I don't think they're zombies, because I can kill them fine (and they are still running with a parent PID of 1). – joepestro Jan 27 '12 at 17:45

I've seen where a pseudo-terminal's process will remain until it receives input. To test this case, after you see the lingering process in the ps list, send a wall and a short message. The process should then disappear.

share|improve this answer

You must log in to answer this question.

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