From owner-freebsd-hackers Tue Oct 10 07:43:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA10432 for hackers-outgoing; Tue, 10 Oct 1995 07:43:10 -0700 Received: from feta.cisco.com (feta.cisco.com [171.69.1.158]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA10403 for ; Tue, 10 Oct 1995 07:42:59 -0700 Received: from [198.92.113.35] ([198.92.113.35]) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id HAA14795; Tue, 10 Oct 1995 07:41:46 -0700 X-Sender: stu@feta.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Oct 1995 07:43:37 -0700 To: Bruce Evans , pst@cisco.com From: stu@cisco.com (Stu Phillips) Subject: Re: FleeBSD and XNTPD Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk 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