Should the login shell be run in its own process group?

I use a rather unusual login shell with no job control (es). It does not claim its own process group. When I hit Ctrl-C, the shell exits. From a bit of tracing, I gather that it catches the SIGINT just fine, then gets another which kills it. Possibly, there is a bug in the shell's signal handling code, but this does not happen in the release iTerm2, nor does it happen in Terminal.

I wrote a small wrapper program that creates its own process group and grabs the terminal with tcsetpgrp() before it execs the shell. When I use this instead of the login shell, the problem goes away.

Hence my suggestion: Perhaps iTerm2 ought to create a new process group for the login shell? I notice that Terminal does so:

-+= 00001 root /sbin/launchd
 \-+= 13144 hanche /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
   \-+= 13145 root login -pf hanche
     \-+- 13146 hanche -es

(In this pstree output, process group leaders are marked with an = sign.)

As I have a workaround (and probably ought to incorporate it into es itself), I can live with this not receiving a high priority. (Thanks for giving us iTerm!)

Oh, the details: iTerm2 Build 2.9.20160206 (the beta), OS X 10.11.3.

Milestone changed to Ship 3.0

There was a bug where we didn't exec /bin/login if you selected a directory other than your home directory in Prefs > Profiles > General. So that might be your issue; I imagine this is login's job anyway. Without such a "custom" directory, I get this:

 |-+= 86660 gnachman /Applications/iTerm.app/Contents/MacOS/iTerm2
 | \-+= 89223 root login -fp gnachman
 |   \-+- 89224 gnachman -es

Does this seem right to you?

No, I never selected any directory other than my home directory. Here is what I get in the standard setup:

-+= 00001 root /sbin/launchd
 \-+= 00249 hanche /Applications/iTerm.app/Contents/MacOS/iTerm2 -psn_0_36873
   \-+= 44035 hanche /Applications/iTerm.app/Contents/MacOS/iTerm2 --server log
     \-+- 44036 root login -fp hanche
       \-+- 44037 hanche -es

Remarkably, my login process is not a process group leader, whereas yours is. I certainly would have expected login to become a process group leader. I wonder why it does so for you, but not for me? But given that it doesn't, it seems to be up to iTerm to take care of it.

I think I pasted the wrong thing there (that was from 2.1.4, not 2.9). Here's what mine looks like:

 |-+= 03799 gnachman /Applications/iTerm.app/Contents/MacOS/iTerm2
 | \-+= 03804 gnachman /Applications/iTerm.app/Contents/MacOS/iTerm2 --server login -fp gnachman
 |   \-+- 03805 root login -fp gnachman
 |     \-+= 03806 gnachman -tcsh

versus Terminal.app:

 |-+= 86662 gnachman /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal
 | |-+= 86663 root login -pf gnachman
 | | \-+= 86665 gnachman -tcsh
 | |   \-+= 04038 gnachman pstree

One difference is that we spawn login from a server, and the server gets to be the process group leader. I don't understand why the child job of the terminal becomes a process group leader.

I tried adding this just before execvping login, but no luck:

    tcsetpgrp(0, getpid());

My grasp of process groups is very shaky, though. What exactly did you do when you added tcsetpgrp to your code?

You need to use setpgid, then tcsetpgrp. But you have to block some signals during the latter call. It took me a while to figure out; I attach the entire source of the program I wrote. I specify the following command to be run by iTerm2:

/opt/pkg/bin/setpgid /opt/pkg/bin/es -l

setpgid.c

Addendum: I learned how to do this from W. Richard Stevens's Advanced programming in the UNIX environment. But I did not succeed until I looked at the bash source code to find out what they did. Tricky stuff!

Thank you! I also paged through my W Richard Stevens this weekend, which was fun but similarly fruitless (though it did impress my wife!). That looks pretty easy to pull in.

How did you figure out which signals to block? Mac OS's man page is silent on the matter; the Linux man page says you need to block SIGTTOU.

Status changed to closed

Fixed in commit e768c4e8. Please review the change because this is kind of scary and slightly outside my comfort zone!

I really don't know of any strong reason to block signals other than SIGTTOU. While googling, I have come across code blocking SIGTTIN and SIGTSTP too, without any explanation. I think the bash source code is the only place I've seen blocking SIGCHLD as well. In any case, overdoing this for the duration of a single system call is probably fairly harmless.

Your code looks good to me. But it's outside my own comfort zone as well.

I am currently on vacation, with limited bandwidth. So I think I'll wait until I get home later in the week to download a nightly build so I can test it in practice.

Have a nice vacation and let me know what you think when you get back!

I downloaded the latest nightly (iTerm2-2_9_20160324-nightly.zip), and it does indeed seem that the problem is fixed. Thanks!