Re: bin/51556: less(1) generates SIGTTOU if lacking a controlling terminal

[Jan Schaumann <jschauma%netmeister.org@localhost>]

The following reply was made to PR bin/51556; it has been noted by GNATS.

From: Jan Schaumann <jschauma%netmeister.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/51556: less(1) generates SIGTTOU if lacking a controlling
 terminal
Date: Wed, 12 Oct 2016 22:52:51 -0400

 David Holland <dholland-bugs%netbsd.org@localhost> wrote:
   
 >  Creating a new process group does not result in the process it invokes
 >  not having a controlling terminal. Unless you mean it creates a new
 >  session; but it doesn't:
 
 What I mean is that the command invoked by timeout(1) will end up in a
 process group that is different from the process group with the
 controlling terminal.
 
 For the purposes of this bug, how we end up in this situation is
 probably irrelevant, and the timeout(1) invocation is just one example
 that happened to be how I came across this issue.  You can recreate it
 without invoking timeout(1) by running this:
 
 --
 #include <errno.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <termios.h>
 #include <unistd.h>
 
 int
 main(int argc, char ** argv) {
 	struct termios otty;
 	int no_tty;
 
 	if (setpgid(0, 0) == -1) {
 		fprintf(stderr, "Unable to setpgid: %s\n", strerror(errno));
 		exit(1);
 	}
 
 	no_tty = tcgetattr(fileno(stdout), &otty);
 
 	if (!no_tty) {
 		if (tcsetattr(fileno(stderr), TCSANOW, &otty) == -1) {
 			fprintf(stderr, "Unable to tcsetattr: %s\n", strerror(errno));
 			exit(1);
 		}
 	}
 	return 0;
 }
 --
 
 You can trigger the issue by invoking it as:
 
 $ /bin/sh -c ./a.out
 
 The process details might end up like this:
 
 $ ps x -o pid,ppid,pgid,tpgid,stat,comm | egrep "(/bin/sh|a.out)"
 15885 18364 15885 18364 T    ./a.out 
 18364  7159 18364 18364 I+   /bin/sh 
 
 /bin/sh has the controlling terminal, but a.out does not.  tcsetattr(3)
 here triggers SIGTTOU and suspends the process.  This is the behaviour I
 observed in Debian's more(1), and I see similar behaviour in our
 less(1), but I haven't been able to pinpoint the code triggering it.
 
 -Jan