[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [leafnode-list] Error Message
On Mon, Jul 17, 2000 at 05:16:49PM +0200, Cornelius Krasel wrote:
> What kind of system are you using? I am running 1.9.14 on a glibc-2.1.2
> based Linux system (SuSE 6.3), and I never encountered this problem.
> What is your output of
I use glibc-2.1.3 (I built it myself; actually my entire system is built
myself; I don't believe in using distributions).
> ? AFAIK this is the only way of finding out about the glibc version;
> in my case, the relevant information looks like this:
nexus@thune[10:47am]~(501) ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 13 Jul 2 12:46 /lib/libc.so.6 -> libc-2.1.3.so*
> If this turns out to be a problem with a glibc version, I expect a lot
> of fun in the near future *sigh* .
I'm sure the glibc folks will be happy to tell you it's not a bug in glibc
but in leafnode. :->
And to be honest, as curt and as rude as the glibc folks can be, they're
usually not wrong. Matter of fact, following bug-glibc for a couple of
years now, I've only seen them wrong once.
Jeff mentioned he was running RedHat 6.2. And from looking at the RPMS on
an ftp.us.kernel.org site, it looks like it too comes with 2.1.3:
ftp> dir *libc*
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
-rw-r--r-- 1 ftp ftp 1379628 Nov 17 1999 compat-glibc-5.2-220.127.116.11.i386.rpm
-rw-rw-r-- 1 ftp ftp 9381877 Mar 8 14:40 glibc-2.1.3-15.i386.rpm
> BTW, is it possible to get a filename from a FILE descriptor?
Not portably. Once the file is open, there is no need for the pointer to
care. It's just acting against inodes. So unless the system specifically
kept the value for debugging reasons, I doubt it. And I don't think at
all with glibc (FILE* really is an opaque pointer). On linux, you could
probably use fileno(FILE*) to grab the file descriptor, and then look
things up in /proc/self/fd using readlink. Of course, that's pretty
Linux specific, and definitely better only be used for debugging.
(Would use fetchnews in the follow example if it was running at the moment.)
thune:~# ls -l /proc/`pidof inetd`/fd | head
lrwx------ 1 root root 64 Jul 17 10:58 0 -> /dev/null
lrwx------ 1 root root 64 Jul 17 10:58 1 -> /dev/null
lrwx------ 1 root root 64 Jul 17 10:58 10 -> socket:
lrwx------ 1 root root 64 Jul 17 10:58 11 -> socket:
lrwx------ 1 root root 64 Jul 17 10:58 12 -> socket:
lrwx------ 1 root root 64 Jul 17 10:58 13 -> socket:
lrwx------ 1 root root 64 Jul 17 10:58 14 -> socket:
lrwx------ 1 root root 64 Jul 17 10:58 15 -> socket:
lrwx------ 1 root root 64 Jul 17 10:58 2 -> /dev/null
then something like:
thune:~# grep 196 /proc/net/*
/proc/net/tcp: 21: 00000000:0019 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 196
Though I'm not certain the  from socket: really refers to that
line in /proc/net/tcp or not. Just a WAG. (Would have to delve into
kernel code to verify). I suspect it's possible to use netstat or some
related tool to get that info, but I'm not 100% certain.
Though, I guess if it came back as a socket, you could just as easily use
Umm.... sorry.... sorta rambled on there....
Mike Castle Life is like a clock: You can work constantly
dalgoda@xxxxxxxxxxxxx and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list