rsm@ut-ngp.UUCP (Robert S. Maier) (07/04/86)
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. I think I have traced this to the following piece of code in Mail's send.c: /* * Prepend a header in front of the collected stuff * and return the new file. */ FILE * infix(hp, fi) struct header *hp; FILE *fi; { ...<lines omitted>... c = getc(fi); while (c != EOF) { putc(c, nfo); c = getc(fi); } if (ferror(fi)) { perror("read"); return(fi); } 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? Robert Maier ARPA: rsm@carl.ma.utexas.edu / rsm@ngp.utexas.edu Dept. of Math. UUCP: ..{ihnp4, allegra, seismo!ut-sally}!ut-ngp!rsm Univ. of Texas AT&T: (512)471-7711
jim@cs.strath.ac.uk (Jim Reid) (07/06/86)
In article <3610@ut-ngp.UUCP> rsm@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@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"