From owner-freebsd-hackers  Tue Oct 10 17:36:45 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id RAA13269
          for hackers-outgoing; Tue, 10 Oct 1995 17:36:45 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA13264
          for <hackers@freebsd.org>; Tue, 10 Oct 1995 17:36:34 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA12603; Wed, 11 Oct 1995 10:32:46 +1000
Date: Wed, 11 Oct 1995 10:32:46 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510110032.KAA12603@godzilla.zeta.org.au>
To: bde@zeta.org.au, pst@cisco.com, stu@cisco.com
Subject: Re: FleeBSD and XNTPD
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk

>>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.

Yes, it calls daemon().  This took more than a browse to see because of the
ifdef forest.

>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.

I put a TIOCSCTTY in refclock_open() for /dev/cuaa0 and it worked.  The
errno ENOTTY can't be returned for TIOCSCTTY on normal ttys.  What
device are you using exactly?  I tested with `server 127/127.3.0' in
/etc/ntp.conf and /dev/cuaa0 linked to /dev/pst0 to get the pst refclock
(Hi pst :-).

>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.

This is normal when there is no controlling tty.

Bruce