> Richard L. Hamilton wrote: > > Is TIOCNOTTY implemented or not? > > > > I see a couple of places where it appears in kernel > code: > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/ > usr/src/uts/common/io/gentty.c#309 > > where it appears to be explicitly _not_ done, > > and > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/ > usr/src/uts/common/os/streamio.c#5674 > > where it looks like it does get done. > > > > In the typical use, one applies that ioctl to > /dev/tty to abandon the > > association of a process from its controlling > terminal. In that use, > > would it encounter the streamio code first, i.e. > would it work? > > > > It's easier and cleaner than some alternatives in > certain situations... > > Yes, it's implemented. The streamio.c strioctl() > implementation is the > real one. The gentty.c module is a red herring. > It's part of the > bscure "sy" driver ... which has no man page and > dates back to the USL > implementation. I have no idea what it does. :-/ > > 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). -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
