The danger of specific errno values

January 16, 2006

One of the things I've learned the hard way in writing Unix programs is that you should almost never expect to know all of the errno values that system calls can return. In theory it's documented in the manpages, but in practice a manpage's list is never comprehensive. The safest thing to do is to assume that any system call can return almost any errno value.

The example I remember most vividly is that our SMTP server daemon used to carefully check the result of accept(). If there was an error and it was anything besides EAGAIN, the daemon decided that something was undoubtedly broken and therefor it should die. Unfortunately, it turns out that on some systems accept() can also return ECONNRESET, because people can initiate a TCP connection and then terminate it before the SMTP daemon gets a chance to accept() the new connection.

Until we caught this and fixed it, the result was that every so often (usually under periods of high load), the daemon would die mysteriously. Whoops.

This also points out another danger with checking specific errno values: they can change over time. So even code that was perfect and correct when it was written can drift into having problems over time and new systems, unless you recheck and revise it all the time.

(Our SMTP server daemon's code was probably perfectly correct for BSD systems of the early 1990s, for example.)

Comments on this page:

By John Wiersba at 2018-12-27 02:02:23:

I'm not clear what you're suggesting here. Isn't logging the error code and aborting the right thing to do with unexpected errors? Did the original programmer have any other choice, given that she didn't know about the special use of ECONNRESET under these circumstances?

Written on 16 January 2006.
« How not to set up your DNS (part 8)
Some words of wisdom for all ISPs »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jan 16 00:03:45 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.