Error with read() function in C program

[Curtis Deese]

Here's something I found while researching 'read(2) can return EINVAL for unaligned access to block devices':

The read system call will return EINVAL if the current file offset is not a multiple of the block size.

[rick jones]

There is no such thing as a block size or alignment for a TCP socket. TCP is a byte-stream.

[Curtis Deese]

I compiled the C program 32-bit. Now I am getting the following error in the log:

-----
7635-15:50:24.529-log -- Commiting After Cache. --
7635-15:53:17.624-log Unable to read from client (0/8) errno(25)

7635-15:53:17.629-log sd : '3'
7635-15:53:17.629-log buffer: '99960000'
------
Notice that the errno changed from 22 to 25. 25 is ENOTTY (Not a typewriter.) Why am I getting the errno=25 and how do I resolve it?

[James R. Ferguson · Accepted solution]

Hi Curtis:

> Why am I getting the errno=25 and how do I resolve it?

This occurs when STDOUT isn't associated with a terminal, as for example with a daemon-ized program or one run as a crontask.

Regards!

...JRF...

[Curtis Deese]

Then, if I do not force termination of the program on errno=25, it should work, right?

[rick jones]

Um, I thought that errno was only valid when read() returned -1. That it has gone from 22 to 25 could simply be a function of reading uninitialized data from different places between 32 and 64 bit.

Again, a read return of zero means the remote end of the TCP connection has called close or shutdown. Or at least it is supposed to.

[Curtis Deese]

How do I handle the errno=25, since it is not reading from the client? stdout is a log file, not the terminal.

[rick jones]

My comment about uninitialized data was meant to convey that you should not consider errno to hold a valid value *unless* read() returns -1. As read() is returning zero, there is no reason to believe that errno is actually being set to an errno value.

One way to confirm this (hopefully Dennis can confirm) I suppose is to explicitly set errno to 0 before the call to read() and then see what it says after.

I think you are chasing after red herrings. Read return of zero against a file descriptor associated with a TCP connection means the remote has closed his end of the connection. The remote has indicated it will be sending no more data to be read. Further, read return of zero is given only after all previously sent data has been "consumed" (read) it means you have already seen all the data you are going to see.

If this is then happening at an unexpected time, it suggests not a problem with the read() call (well apart from the broken assumption about always getting sz bytes) but with the "application protocol" between your client and server. Somehow they have gotten out of sync with one another.

[Dennis Handly]

>rick: One way to confirm this (hopefully Dennis can confirm) I suppose is to explicitly set errno to 0 before the call to read() and then see what it says after.

(You're too quick for me.)
Right, you have no business looking at errno, unless you get that -1 return:
When an end-of-file is reached, a value of 0 is returned. Otherwise, a -1 is returned and errno is set to indicate the error.

[Curtis Deese]

The problem is with the calling program shutting down with an error. Thanks everyone for your help.

Curtis