Edward Pilatowicz 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.
I don't think it should be removed, and it's nice that you folks added
it. I wasn't in any way suggesting removal.
The reasons I'd recommend avoiding _using_ it are:
- fork/setsid/fork prevents you from accidentally acquiring a new
controlling tty in the future. This can happen in surprising ways,
such as having a logging library open the console, or just a stray
open() unadorned by O_NOCTTY, if you're still a process group
leader after you do TIOCNOTTY.
- The setsid call will work on older versions of Solaris, but
TIOCNOTTY will not. Though this is opensolaris.org, many of us
working on OpenSolaris still need to support S8, so it can be an
important consideration.
- fork/setsid/fork always works and doesn't require you to have
access to a stream opened on the controlling tty, doesn't require
you to be the process group leader, or anything else. It "just
works."
> 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.
> ---8<---
So, your program will run as expected if it's just run by itself, but if
it's put in a pipeline, it'll fail to release the controlling tty, right?
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
