On Fri, Aug 06, 2010 at 11:35:36AM -0700, Richard L. Hamilton wrote: > > On Fri, Aug 06, 2010 at 01:05:38PM -0400, James > > Carlson wrote: > > > Richard L. Hamilton wrote: > > > >James Carlson wrote: > > > >> For what it's worth, I would use > > > >> fork()/setsid()/fork() to disclaim a > > > >> controlling tty. It's simple and always works. > > > >> (Though, notably, it > > > >> oes not get you outside of an existing contract, > > > >> which is sometimes an > > > >> important distinction for programs that operate > > as > > > >> daemons.) > > > > > > > > That's exactly what I wanted to avoid, using a > > sort of > > > > semi-daemonizer program that would leave > > backgrounding > > > > up to the invoker, so that if the invoker wished, > > it could > > > > collect status to discover any failures. That's > > a little > > > > tricky to do with fork()/setsid()/fork(), taking > > into account > > > > the possibility of non-zero return codes or > > signals (with or without > > > > core dumps). > > > > > > That's what Solaris contracts are (at least partly) > > about. They allow > > > you to monitor children that may go through > > multiple forks. > > > > > > I can't say I'd recommend TIOCNOTTY for any new > > code intended to run on > > > Solaris. But good luck. ;-} > > > > > > > i implemented TIOCNOTTY support as part of the > > original brandz project. > > we needed it for the lx brand, since > > fork()/setsid()/fork() wasn't > > really an option for emulating TIOCNOTTY. since then > > the lx brand has > > been retired, but we've kept TIOCNOTTY for > > compatibility. it's a public > > interface documented in termio.7i (on nevada at > > least). i don't think > > there's any reason for us to remove it, so i don't > > really think there's > > any reason to recommend not using it. > > > > that said, there is one restriction on the caller of > > the interface. > > specifically, the process calling it must be a > > session group leader. > > here's the man page blurb from nevada: > > > > ---8<--- > > TIOCNOTTY Takes no argument. Release the > > controlling > > terminal associated with > > the current > > processes session group. The > > calling pro- > > cess must be the session group > > leader to > > issue this ioctl. > > > Hmm...I just compiled a couple of test programs (although not > compliant with that restriction you just mentioned, which > incidentally does _not_ apply to other implementations > (where TIOCNOTTY by a tty group leader process generates > a SIGHUP for all processes in the group and disassociates them > all from their controlling terminal, while any other process > doing it only disassociates itself; the latter case being at > least as useful as the former, I would think). > > On snv_97, one (opening /dev/tty and applying the ioctl there) > resulted in the ioctl failing with EINVAL (gentty.c rejecting it, > I presume). The other applied it to stdin, which was a terminal. > That "succeeded" (didn't return -1), but ps showed the process > still associated with its controlling terminal. >
i took a quick look at gentty.c and while it rejects this ioctl today it wouldn't be too difficult to add support for it. i filed an RFE on this: 6975392 /dev/tty should support TIOCNOTTY ed _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
