Date: Tue, 10 Oct 1995 07:43:37 -0700 From: stu@cisco.com (Stu Phillips) To: Bruce Evans <bde@zeta.org.au>, pst@cisco.com Cc: hackers@freebsd.org Subject: Re: FleeBSD and XNTPD Message-ID: <v02110100aca0334ca661@[171.69.60.153]>
next in thread | raw e-mail | index | archive | help
At 3:56 PM 10/9/95, Bruce Evans wrote: >>>FSETOWN has never worked "right" for ttys in FreeBSD releases. It only >>>works for controlling terminals that are associated with the session of >>>the calling process. Using it may interfere with normal controlling > >>Agreed but doesn't this apply to terminal devices to which there is already >>attached a controlling terminal ? In this instance there is nothing >>hanging on the terminal device at all - ie no login shell or similar. >>Shouldn't the >>rejection of the attempt be made iff there is already a process marked as the >>controlling process ? > >There must be a controlling process for tcsetpgrp() to work. F_SETOWN >shouldn't interfere with tcsetpgrp(). (I'd like F_SETOWN to be completely >independent of the controlling terminal and its process[group]. Since >F_SETOWN applies to file descriptors, I would expect the process[group] >to be per-fd. Is that too general?) > >>See above - how would a process get itself marked as the recipient of the >>signal without being able to use F_SETMODE or TICGSPGP (both of which >>should map to the same thing) ? > >It can't be done that way. Under FreeBSD, the following all seems to be >necessary: > > setsid(); > ioctl(fd, TIOCSCTTY); > fcntl(fd, F_SETOWN, getpid()); > fl = fcntl(fd, F_GETFL); > fcntl(fd, F_SETFL, fl | O_ASYNC); > >Plus error checking and setting up the signal handler of course. > Well, tried all this and alas still no joy... The setsid() call fails - returning -1 - a browse through ntpd.c shows that setsid() has already been called when the original controlling terminal is detached. Next the TIOCSCTTY fails - again with inappropriate IOCTL for device - I checked the file handle that is returned by open in refclock_open and by jove its the same one being used here - so it should work. To further shroud this thing in mystery, I added a call to ioctl(TIOCGPGRP) to get the controlling process for the fd and that call also fails with inappro. ioctl. Any ideas what's going on ? Stu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02110100aca0334ca661>