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. ed _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
