On Sun, Aug 08, 2010 at 09:49:32AM -0700, Richard L. Hamilton wrote: > > 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.
in solaris we can't do this without a major change to the way ctty's work, because as i mentioned before, a ctty is associated with a session, not a process. we could probably dissassociate a ctty from a non-session leader process by creating a new session for that process, but we don't currently do that today. ed _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
