> 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'll repeat that test on snv_134 (latest publically available) as soon as I get a compiler installed (my snv_134 is x86 under VirtualBox (on a Mac Mini), whereas my snv_97 is SPARC on bare metal; hopefully I can get the compiler installed, given limited resources available for the VM). If the same results hold, I'd say that at most, TIOCNOTTY works when used, probably not as it "should" be on a file descriptor opened via /dev/tty, but rather on any _other_ terminal file descriptor, and then only if your restriction (must be session group leader) is met. If that's the case, it might as well be dead code, because there's no situation I can think of compatible with other implementations where it does anything at all...which would be unfortunate, because where it's traditionally supported, it's far and away the easiest way to do what it does, with the least side-effects, meaning that code originating on such a system will probably use it unless the author went out of their way to be standards-compliant. I'll report the results of my snv_134 test if I can get the compiler installed... -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
