From: mjinks Date: 01:08 on 23 Aug 2006 Subject: errno=104 Cool. Thanks, that's really helpful. Somewhere along this chain of client<=>middleware<=>server, somebody encountered some difficulty and killed my connection. Well thank goodness they threw an error! An "errno=104"! Now, I wonder who did the throwing? And in what .h file buried deep in whoever's bowels might I find out what an "errno 104" FUCKING MEANS? Sequel: as it happens, client and server in this case are both part of the same package, so it seemed like a reasonable guess to go pawing around in that package's headers. Yay, 53 of them define something as a "104", and of those 53 header files, none has a name with "err" anywhere in it. Lovely. This of course assumes that the numbers in the headers and the numbers reported at runtime are even in the same base, such that my naive text string search is even vaguely on the right track. I mean honestly, numeric error codes, why the hell bother? Why not just die and keep your trap firmly shut so I'll know right away that I'm going to be running two or three different processes inside debuggers, rather than pretending to try to be informative? Oh wait, I get it. Never mind. Loathe, -j
From: dom (Dominic Mitchell)
Date: 10:42 on 23 Aug 2006
Subject: Re: errno=104
On Tue, Aug 22, 2006 at 07:08:37PM -0500, mjinks@xxxxxxxx.xxx wrote:
> Cool. Thanks, that's really helpful. Somewhere along this chain of
> client<=>middleware<=>server, somebody encountered some difficulty and
> killed my connection. Well thank goodness they threw an error! An
> "errno=104"! Now, I wonder who did the throwing? And in what .h file
> buried deep in whoever's bowels might I find out what an "errno 104"
> FUCKING MEANS?
Normally, that's one of the standard Unix errno codes, which you should
be able to grep for. It should be available in the include
<sys/errno.h> but that's too sensible for Linux.
% egrep -w 104 /usr/include/**/errno.h
/usr/include/asm-generic/errno.h:#define ECONNRESET 104 /* Connection reset by peer */
Your're spot on about the message though, as there is a lovely
strerror(3) function for turning those error codes into nice human
readable strings. You don't have to be a genius to find it.
-Dom
From: Jarkko Hietaniemi Date: 11:14 on 23 Aug 2006 Subject: Re: errno=104 Dominic Mitchell wrote: > On Tue, Aug 22, 2006 at 07:08:37PM -0500, mjinks@xxxxxxxx.xxx wrote: >> Cool. Thanks, that's really helpful. Somewhere along this chain of >> client<=>middleware<=>server, somebody encountered some difficulty and >> killed my connection. Well thank goodness they threw an error! An >> "errno=104"! Now, I wonder who did the throwing? And in what .h file >> buried deep in whoever's bowels might I find out what an "errno 104" >> FUCKING MEANS? > > Normally, that's one of the standard Unix errno codes, which you should > be able to grep for. It should be available in the include > <sys/errno.h> but that's too sensible for Linux. > > % egrep -w 104 /usr/include/**/errno.h > /usr/include/asm-generic/errno.h:#define ECONNRESET 104 /* Connection reset by peer */ You are being too kind to Linux' tardastic maze of include files. /usr/include/errno.h includes /usr/include/bits/errno.h includes /usr/include/linux/errno.h includes /usr/include/asm/errno.h includes /usr/include/asm-generic/errno.h, which seems to define most of the Econstants, but each of the headers seems to have bits and pieces of defines and undefines, some conditional and some not. Really, bits/errno.h, asm/errno.h? BITS? That's the lamest excuse for a naming convention evah. ASM? How did defining a few cpp constants become ASM? asm-generic is just adding insult to the insult.
From: Nik Clayton Date: 11:32 on 23 Aug 2006 Subject: Re: errno=104 Dominic Mitchell wrote: > On Tue, Aug 22, 2006 at 07:08:37PM -0500, mjinks@xxxxxxxx.xxx wrote: >> Cool. Thanks, that's really helpful. Somewhere along this chain of >> client<=>middleware<=>server, somebody encountered some difficulty and >> killed my connection. Well thank goodness they threw an error! An >> "errno=104"! Now, I wonder who did the throwing? And in what .h file >> buried deep in whoever's bowels might I find out what an "errno 104" >> FUCKING MEANS? > > Normally, that's one of the standard Unix errno codes, which you should > be able to grep for. It should be available in the include > <sys/errno.h> but that's too sensible for Linux. > > % egrep -w 104 /usr/include/**/errno.h > /usr/include/asm-generic/errno.h:#define ECONNRESET 104 /* Connection reset by peer */ Caution advised. ECONNRESET is defined to be 54 on FreeBSD, and 131 on Solaris. N
From: A. Pagaltzis
Date: 12:23 on 23 Aug 2006
Subject: Re: errno=104
* Dominic Mitchell <dom@xxxxxxxxxxxx.xxx> [2006-08-23 11:45]:
> Normally, that's one of the standard Unix errno codes, which you should
> be able to grep for. It should be available in the include
> <sys/errno.h>
You can use Perl’s $! magic to avoid all the faffing around:
$ perl -le'$!=104;print"$!"'
Connection reset by peer
Regards,
From: Juerd
Date: 13:14 on 23 Aug 2006
Subject: Re: errno=104
A. Pagaltzis skribis 2006-08-23 13:23 (+0200):
> You can use Perl???s $! magic to avoid all the faffing around:
> $ perl -le'$!=104;print"$!"'
> Connection reset by peer
Let's golf.
perl -le'print$!=104'
Or, if you don't mind extra fluff:
perl -e'die$!=104'
Juerd
From: Yossi Kreinin Date: 18:08 on 26 Aug 2006 Subject: Re: errno=104 Dominic Mitchell wrote: > > Your're spot on about the message though, as there is a lovely > strerror(3) function for turning those error codes into nice human > readable strings. You don't have to be a genius to find it. > > -Dom > strerror/perror/herror/whatever are surely a great family of functions since: 1. "Is a directory", contrary to 54 (or whatever), is awfully informative (especially if you have exactly one directory) 2. I think these messages are pretty much the only thing actually affected by "locales" (the only effect of choosing Japanese as the "session language" seems to be the Japanese perror messages) One awesome application doing lots of file I/O is BitKeeper (installed suid root, so you can screw up others' "revision-controlled" files, occasionally asking a sysadm to unscrew them back). BitKeeper is very careful to report all errors, such as "error plocking file: not owner". To find out WHICH file, I usually use strace (and boy does it mess with A LOT of files for doing just about ANYTHING). I wonder how is it possible to strace a suid root process, and what creative uses exist for that? I once looked at some Windows CE guts-related sources. You have this huge networking module, reporting errors as integeres (what else?). Then it's wrapped by a thin layer of shite, which checks for errors and returns a SINGLE integer (what else?) indicating that networking code failed, and throws the more specific integer away. So there's this useless tree of error numbers, eventually culminating in a boolean "tough luck!" message to the user. -- Yossi
From: peter (Peter da Silva) Date: 18:16 on 26 Aug 2006 Subject: Re: errno=104 > I once looked at some Windows CE guts-related sources. You have > this huge networking module, reporting errors as integeres (what > else?). Then it's wrapped by a thin layer of shite, which checks > for errors and returns a SINGLE integer (what else?) indicating > that networking code failed, and throws the more specific integer > away. So there's this useless tree of error numbers, eventually > culminating in a boolean "tough luck!" message to the user. Windows is worse. There you have multiple layers which not only throw away the underlying errors, they *make error codes up* based on what the programmer thought was most likely, or to try and make some application that did something wrong if it got the "wrong" error code "not break" on a new version of Windows, or because of sheer stupidity... So you end up with network errors being reported as premissions errors, full disks being reported as permission errors, and permission errors being reported as full disks! Worse, because of the increasing use of shared libraries as "the API" instead of system calls, I'm starting to see the same things happen in what are otherwise basically UNIX systems, like Linux and OS X.
From: Michael Leuchtenburg Date: 02:44 on 31 Aug 2006 Subject: Re: errno=104 Ah, errno. How well I've learned to hate you from MySQL's error messages. "Something bad happened! Errno 131! But I'm not going to tell you what that means!" MySQL does, however, come with a perror command. Thusly: $ perror 131 MySQL error code 131: Command not supported by database Amazing! Filling the gaps with a commandline tool! Too bad I'm usually remote from my database. On the plus side, it handles system errors too: $ perror 104 OS error code 104: Connection reset by peer Still, MySQL folks? Think you could just call perror and return the string along with the numeric code? It'd be a good bit less hateful.
Generated at 10:25 on 16 Apr 2008 by mariachi