Xref: utzoo comp.unix.questions:29446 comp.sys.att:11996
Path: utzoo!attcan!uunet!snorkelwacker.mit.edu!spool.mu.edu!uwm.edu!linac!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.questions,comp.sys.att
Subject: Re: uucp & rfs
Message-ID: <1991Feb28.202549.6856@chinet.chi.il.us>
Date: 28 Feb 91 20:25:49 GMT
References: <3816@wb3ffv.ampr.org>
Organization: Chinet - Chicago Public Access UNIX
Lines: 26

In article <3816@wb3ffv.ampr.org> wmark@wb3ffv.ampr.org (Mark Winsor) writes:
>We currently have rfs between two att machines. I was wondering if there was
>a way to get uucp to use the devices on the second machine (/mach2/dev/tty43)
>for example. It appears to me that it assumes all devices are in /dev. Any
>way around this?

I just tried this with some '386 machines and it came remarkably close
to working.  I just used the full pathname of the mounted device in the
Devices file and it found it just fine.  Apparently uucico and cu place
kernel locks on the device itself, because attempting to access the
same device from both machines resulted in error "filelock: F_SETLK failed".
Cu seemed to work just fine on the RFS'ed device.  However, using uucp I
would get logged into a remote machine and then uucico would fail after
the protocol handshake.

rmesg - 'P' got PGed
wmesg 'U'g
ASSERT ERROR (uucico) pid: 422 (2/28-14:08:54) PKXSTART ret (-1) [File: pk1.c,
 LINE: 338]

Does anyone know what this means?  Do some kinds of ioctl()'s not work over
RFS even among the same kind of machines, perhaps?
(This is with the stock uucp that comes with AT&T's SysVr3.2).

Les Mikesell
  les@chinet.chi.il.us