Ferror bug on a Sun client?

[Jim Reid]

In article <3610 at ut-ngp.UUCP> rsm at ut-ngp.UUCP writes:
>We have had considerable trouble with /usr/ucb/mail (also known as
>Mail) on a diskless Sun 2/50 which is a client of a diskful server.
>Messages typed in are not sent, although the headers are.  Moreover,
>after one types ^D (i.e., EOF) to end the message the system responds
>with "read: I/O error".  This happens only on the client; never on the
>server.
>
>	<lines deleted >
>
>Can anyone suggest why 'ferror' should return an error condition on
>the keyboard input stream if the program is run on the client, but
>never on the server?  Has anyone ever encountered a similar problem?

Simple. The NFS or ND server is in trouble. When your program does a read,
the server doesn't respond to the read request quickly enough (or at all)
and the kernel interprets the failure as EOF which it returns to your
program. The mail program keeps your mail message in a temporary file in
/tmp while you type it in. It keeps the headers to itself. When it tries
to re-read the file in /tmp to pass it to sendmail, your ND or NFS server
croaks and mail then gets EOF AFTER it has given the headers to sendmail -
hence the mail messages with no body.

Check out your server machine - either the NFS and ND daemons are dead or
too busy to handle the remote requests. I don't see what you can do unless
you make /tmp a symbolic link to somewhere on a filesystem that is hard
mounted on the client. In that case, mail would barf if it couldn't make
the temporary file because the NFS server was down or too busy. (You pays
your money and takes your choice.....)

We have a ropey NFS server which exports /usr/lib. Sometimes compiles on
client hosts fail (premature EOF in /usr/lib/lib???.a) because the server
is too busy. We just live with it for now - there's no cash for new h/ware.
For us hard NFS mounts - which wouldn't make much difference anyway -
are out.

		Jim
-- 
ARPA:	jim%cs.strath.ac.uk at ucl-cs.arpa, jim at cs.strath.ac.uk
UUCP:	jim at strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim
JANET:	jim at uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"