> 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). > > > > if a session group leader issues a TIOCNOTTY, all > processes in the > session group will get SIGHUP. see > freectty_signal(). > > in the case of a non-session leader issuing > TIOCNOTTY, that will fail. > the reason is that cttys on solaris are bound to > sessions and not > processes. so you can't disassociate a ctty for a > single process on > solaris, you can only do it for all the processes in > a session. > > > 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. > > > > perhaps there's a bug with ps or proc reporting? i'm > not sure why your > seeing that. > > > 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. > > > > well, the behavior we implemented seemed to be > sufficient for running > linux apps at the time. i don't remember > specifically what apps used > this functionality, but i'd guess things like shells > and expect. > > > I'll report the results of my snv_134 test if I can > get the compiler > > installed... > > well, it sounds like you want to allow a single > process to > dissassociate. that isn't possible. in that case > the process i would > think the process that wants to disassociate should > either: > > - create it's own session group > > - just close it's tty (in which case as long as it's > not in the > foreground of the session group, it will never get > any signals if/when > the ctty is closed. > if that doesn't work for you then i recommend > following james > suggestion.
Didn't get anywhere with testing on b134. Looks like the scenario of applying it not to a /dev/tty fd, but to a regular terminal fd, may work if it's the session leader (as you said), but that seems to end the session immediately, which might be expected (send a SIGHUP to the session, etc). Why couldn't it, if getsid() != pid, do the equivalent of setsid() (or perhaps more traditionally, the equivalent of setpgid(getpid(),getpid())? The only thing that implements a sort of traditional TIOCNOTTY that I have is Mac OS X 10.6, and, for a non-session leader that applies TIOCNOTTY to an fd obtained by opening /dev/tty, it disassociates it with the controlling terminal an sets its process group the same as its pid, but does not change its session id. -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
