iTerm2 not reaping child processes when killed by init

It looks like the iTerm2 parent process is not reaping its child processes when killed by init (launchd pid 1 process).

I'm using iTerm2 Build 3.1.20170613-nightly on macOS 10.12.5.

Normally, the iTerm2 process tree looks something like:

-+= 00001 root /sbin/launchd
 |-+= 97887 felix /Applications/iTerm.app/Contents/MacOS/iTerm2 -psn_0_26056920
 | |-+= 02154 felix /Applications/iTerm.app/Contents/MacOS/iTerm2 --server /usr/local/bin/zsh -l
 | | \-+= 02155 felix /usr/local/bin/zsh -l

I had a problem which caused the window server to crash after disconnecting the external display on my rMBP.

This causes macOS to restart the window server and show the login screen.

After logging back in, I noticed that all apps did a session restore, but the iTerm2 windows were kept running, in fact one had a running file transfer that was not interrupted by the crash.

I inspected the process tree and found something like this:

-+= 00001 root /sbin/launchd
 |-+= 02154 felix /Applications/iTerm.app/Contents/MacOS/iTerm2 --server /usr/local/bin/zsh -l
 | \-+= 02155 felix /usr/local/bin/zsh -l

So as you can see the parent iTerm2 process was killed and the child processes were adopted by PID 1 (launchd), which is expected behavior on Unix systems.

Normally a process that forks children needs to take care of terminating them if it exits, which is not happening in this case.

The problem with this behavior is that those adopted iTerm2 sessions are now broken in subtle ways. For example starting a MacVim window will fail to connect to the window server and instead start a broken non-gui session with input still arriving in the shell instead of the editor or golang apps mysteriously failing to do name resolution or ssl connections.

I think the proper behavior for iTerm2 would be to clean up its child processes when the parent is killed or terminated.

Another solution would be to somehow detect that the parent process is gone inside an iTerm2 session and show a warning banner that the session is likely broken. This would allow users to keep a crucial process like a big upload or download running, but restart the session as soon as it is convenient.

One of the problems here is that the user might not even notice that the window server has crashed, if he goes away from his or her computer and comes back to the normal login screen, because most apps just restore to their previous state and no error message is shown to the user.

Child processes surviving the UI process's death is a feature (it lets you upgrade iTerm2 without losing your work, and prevents you from losing data in the event of a crash).

Seems reasonable to kill the children when the window server bites it. How the heck do we tell that happened? :)

changed milestone to %Review for next version

A few ideas:

1. Check if the process ID of /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer changes. The exact path probably depends on OS version. This is also not a perfect test since PIDs get recycled.
2. There's probably something else in the kernel process info structures that could be used to identify the launch of a process. Start time combined with PID might work, but clocks are unreliable, so I'd rather not use time if there's something else.