Linux-Development-Sys Digest #764, Volume #8 Thu, 31 May 01 15:13:10 EDT
Contents:
Re: /proc/stat disk_io (Adam Fineman)
Re: /usr/local/include is a file not directory (Bob Glauser)
how to force a core file dump ? (Christophe Dore)
Problems with sources from MS Visual C++ ("Christian Jetter")
Re: how to force a core file dump ? ("Karl Heyes")
Re: how to force a core file dump ? (Adam Fineman)
usleep takes to much time ?! ("Lars Guesmar")
Re: usleep takes to much time ?!
Re: BSD signal (Derek Viljoen)
Re: Kernel Threads (cLIeNUX user)
How to discover File Descriptor leak in programs? ([EMAIL PROTECTED])
Re: EXPORT_SYMBOL ("Norm Dresner")
core dump with -static linked ("Alex Ho")
Re: environment variable confusion (Eric Taylor)
Re: How to discover File Descriptor leak in programs?
----------------------------------------------------------------------------
From: Adam Fineman <[EMAIL PROTECTED]>
Subject: Re: /proc/stat disk_io
Date: Thu, 31 May 2001 09:30:36 -0400
"Nils O. Sel�sdal" wrote:
>
> "Pirabhu" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > hi,
> > I am Pirabhu Raman, a graduate student at the University of Florida.
> > I am working on a load balancing project in which i need the system
> > data of all processors. I would be glad if somebody could explain the
> > exact details of /proc/stat file especially the disk_io entry. I
> > checked the man file but it doesnt provide much help.
> if you install the kernel sources, the
> <kernel-source>/Documentation/filesystems/proc.txt might help you.
> It's located in /usr/src/linux/Documentation/filesystems/proc.txt on my
> installation.
There is lots of good information in
<kernel-source>/Documentation/filesystems/proc.txt. Unfortunately, at
least in the kernel versions the I on my machine, it does not contain
the information that the OP seeks.
--
Adam
------------------------------
From: [EMAIL PROTECTED] (Bob Glauser)
Subject: Re: /usr/local/include is a file not directory
Date: 31 May 2001 06:42:30 -0700
> This file is cdda_interface.h; CDDA is (usually) a part of the xmcd tool
> that lets you play audio CDs in your computer's CDROM drive.
>
> Almost certainly what happened was that you did not have a
> /usr/local/include directory and the install process expected it to
> already exist. Then during the install process, something similar to
> this command was invoked:
>
> cp cdda_interface.h /usr/local/include
>
> If the directory /usr/local/include exists, that will DTRT and create
> /usr/local/include/cdda_interface.h. If /usr/local/include _doesn't_
> exist, then it copies cdda_interface.h to the file /usr/local/include.
>
> Not what you want.
>
> But, this is easily fixed:
>
> # mv /usr/local/include /usr/local/cdda_interface.h
> # mkdir /usr/local/include
> # mv /usr/local/cdda_interface.h /usr/local/include
Thank you, I created the directory, and now files will compile.
------------------------------
From: [EMAIL PROTECTED] (Christophe Dore)
Subject: how to force a core file dump ?
Date: 31 May 2001 06:57:39 -0700
Hi,
I'd like to write handlers error signal (such as SIGSEV, SIGFPE, ...),
but I would like to keep core dump.
How can I force a program to dump a core? (especially in signal
handlers ?)
Thanks,
C.Dore
------------------------------
From: "Christian Jetter" <[EMAIL PROTECTED]>
Subject: Problems with sources from MS Visual C++
Date: Wed, 30 May 2001 16:28:23 +0200
Hi there!
I have to convert a DLL based on a source code which was originally
developed for Windows NT/9x for a Linux application. Fortunately all big
problems like semaphores or os specific system calls have been solved and
the DLL is loaded without any problems into the application. The source code
is compiled by gcc without any errors, the linking works fine and the
resulting .so-file is of a sensible size.
Anyhow there remain mysterious problems with the encryption and decryption
functions using the OpenSSL package linked into the library.
Since I am not very experienced on Linux it is a really hard job for me to
find the bug.
Is there something like a list of typical problems that occur when taking
original Windows-C++ source code for development under Linux. Maybe it is
just a simple problem like different size()-values for the same datatypes or
variables, or string termination problems or something like that. If anyone
can help me I would be very thankful for an e-mail. I have already busted
all deadlines for the project and it would be a pity if all these
Windows-oriented guys would have an another argument against portations for
Linux.
Greetings
Chris
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: how to force a core file dump ?
Date: Thu, 31 May 2001 15:28:48 +0100
In article <[EMAIL PROTECTED]>, "Christophe Dore"
<[EMAIL PROTECTED]> wrote:
> Hi,
> I'd like to write handlers error signal (such as SIGSEV, SIGFPE, ...), but I
> would like to keep core dump.
> How can I force a program to dump a core? (especially in signal handlers ?)
>
how about abort()
karl.
------------------------------
From: Adam Fineman <[EMAIL PROTECTED]>
Subject: Re: how to force a core file dump ?
Date: Thu, 31 May 2001 10:36:17 -0400
Christophe Dore wrote:
>
> Hi,
>
> I'd like to write handlers error signal (such as SIGSEV, SIGFPE, ...),
> but I would like to keep core dump.
>
> How can I force a program to dump a core? (especially in signal
> handlers ?)
>
> Thanks,
>
> C.Dore
abort() will do it, but it may not be safe to use in a signal handler.
POSIX does not require that abort() be reentrant, by it is in some
implementations. If abort() is reentrant in Linux, you're golden.
--
Adam
------------------------------
From: "Lars Guesmar" <[EMAIL PROTECTED]>
Subject: usleep takes to much time ?!
Date: Thu, 31 May 2001 17:29:04 +0200
Hello all,
when I run the following programm
#include <stdio.h>#include <unistd.h>#include <sys/times.h>void
my_usleep(unsigned int microseconds);int main(){ my_usleep(1e6);
my_usleep(1e5); my_usleep(1e4); my_usleep(1e3); my_usleep(1e2);
my_usleep(1); printf("Finished\n");}void my_usleep(unsigned int
icroseconds){ clock_t tick1=-1, tick2=-1; double dClock = -1; struct tms
tStruct1, tStruct2; if((tick1 = times(&tStruct1))== -1) printf("Error time
1\n"); usleep(microseconds); if((tick2 = times(&tStruct2))== -1) printf("Error
time 2\n"); if((dClock = sysconf(_SC_CLK_TCK)) < 0) printf("Error sysconf \n");
printf("usleep(%d) takes %6.2f ms\n", microseconds,
(1000*(tick2 -tick1)/dClock) ); return;}
I get the following output:
usleep(1000000) takes 1010.00 ms usleep(100000) takes 110.00 ms
usleep(10000) takes 20.00 ms usleep(1000) takes 20.00 ms usleep(100)
takes 20.00 ms usleep(1) takes 20.00 ms Finished
Please, can anybody tell me why a usleep(1 usec) takes 20 ms ?
(Linux 2.4, glibc2.2, gcc 2.95.2)
How do I get an exactly 1/1000 sec sleep ?
Thanks
Lars
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: usleep takes to much time ?!
Date: Thu, 31 May 2001 16:37:57 -0000
In article <9f5o4u$29vps$[EMAIL PROTECTED]>,
Lars Guesmar <[EMAIL PROTECTED]> wrote:
>Please, can anybody tell me why a usleep(1 usec) takes 20 ms ?
Because the clock ticks are (on default x86) 10 ms each.
--
http://www.spinics.net/linux/
------------------------------
From: Derek Viljoen <[EMAIL PROTECTED]>
Subject: Re: BSD signal
Date: Thu, 31 May 2001 12:57:25 -0400
Reply-To: [EMAIL PROTECTED]
Okay let's play:
$ man signal
...
NOTES
Signal handlers cannot be set for SIGKILL or SIGSTOP.
Unlike on BSD systems, signals under Linux are reset to their
default behavior when raised. However, if you
include <bsd/signal.h> instead of <signal.h> then signal is
redefined as __bsd_signal and signal has the BSD
semantics. Both versions of signal are library routines built
on top of sigaction(2).
...
Juergen Heinzl wrote:
> In article <[EMAIL PROTECTED]>, Derek Viljoen wrote:
>
>> Does anyone know where the bsd/signal.h file went?
>>
>> I'm using RedHat 6.2. The man page for signal() says that if you want
>> bsd semantics (I'm assuming this means reliable signals...) then include
>> <bsd/signal.h> instead of <signal.h>. But this is not anywhere on my
>> system... (well there is one in bcc ...)
>>
>> I've already surmised that it's not included in bsd-compat. Anyone?
>
> [-]
> info signal -- "In the GNU C Library we use the BSD version by
> default." -- this has been valid for quite some time now. Still
> read through the whole signal handling stuff to learn about all
> the options. I'd problems ages ago with smail for instance due
> to a missing option in its compile time configuration which does
> not cope yet with the "not so new" signal semantics.
>
> Just in case,
> Juergen
--
___ __ _ * [EMAIL PROTECTED]
/ ) _ _ _ / / / . / . _ _ _ * (609) 734-3061 (W)
(_/__/ (/_/__(/__/< (_/ /_/_/_(_)_(/_( )__ * ICBM Addr: 39N 58' 21"
_/ * 74W 47' 49"
------------------------------
From: r@cLIeNUX. (cLIeNUX user)
Subject: Re: Kernel Threads
Date: Thu, 31 May 2001 17:35:49 -0000
[EMAIL PROTECTED]
>Hello Everybody,
> i am writing a kernel module which requires
> reader and writer threads to be written.Kindly help me out
> as to from where i can get information regarding kernel threads
> and also to execute the same.I am working on Red hat Linux(6.2)
> kernel(2.2.14).
>
>thanks in advance,
>somya
You might find the H3rL stuff interesting in
ftp://linux01.gwdg.de/pub/cLIeNUX/interim
It is a Forth-like language installed in the kernel as a thread/daemon.
Rick Hohensee
www.clienux.com
------------------------------
From: [EMAIL PROTECTED]
Subject: How to discover File Descriptor leak in programs?
Date: Thu, 31 May 2001 14:09:30 -0400
Hello,
We have a system with multiple processes. The system runs fine
initially but soon runs out of File Descriptors. One of the process
must have openned files/scokets without closing them. How do you find
out which one is leaking File Descriptors?
Thanks so much.
W.
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: EXPORT_SYMBOL
Date: Thu, 31 May 2001 18:10:27 GMT
Holger Eitzenberger <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ok, before you will ask: i am waiting for the Rubini Book 2nd Edition.
>
> Why and when do i need to use
>
> EXPORT_SYMBOL(function);
>
> The driver i have works obviously without it.
>
> Thanks in advance.
>
> Holger
If you want other kernel code to be able to address variables/functions
within your module by name. Writing
#define EXPORT_SYMTAB
...
int aclMEM_SEG; /* this is global, i.e. outside
any function */
EXPORT_SYMBOL( aclMEM_SEG);
Then any other kernel code can use
extern int aclMEM_SEG;
and reference the value of it directly.
The only time I've ever needed to make things in my modules global within
the kernel is when I have multiple modules which all reference the same
memory structure set up by a single module. You can ask, "Why not just
write one module instead of three?" and I'd answer, "Because I don't have to
load all of them at one time."
Norm
------------------------------
From: "Alex Ho" <[EMAIL PROTECTED]>
Subject: core dump with -static linked
Date: 31 May 2001 18:10:39 GMT
Hi,
I am using g++ version egcs-2.91.66 on Redhat 6.2. When my app is linked
with -static, it core dumps as soon as it starts.
Here is the stack trace display in gdb:
#0 0x8132c29 in __syscall_error_1 () at herrno.c:34
#1 0x8123643 in fcntl (fd=1, cmd=1) at wrapsyscall.c:77
#2 0x8132b10 in check_standard_fds () at
../sysdeps/generic/libc-start.c:110
#3 0x8132bc4 in __libc_start_main (main=0x80481d4 <main>,
argc=1,argv=0xbffffcc4,
init=0x80480b4 <_init>, fini=0x8192e48 <_fini>, rtld_fini=0,
stack_end=0xbffffcbc)
at ../sysdeps/generic/libc-start.c:60
Current language: auto; currently c
Does anyone know why?
Thanks in advance.
In addition, I did bt in gdb on the core file, I got this:
[alex@jade pioneer]$ gdb bin/pioneer core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `pioneer'.
Program terminated with signal 11, Segmentation fault.
#0 0x8132c29 in __syscall_error_1 () at herrno.c:34
34 herrno.c: No such file or directory.
(gdb) bt
#0 0x8132c29 in __syscall_error_1 () at herrno.c:34
#1 0x8123643 in fcntl (fd=1, cmd=1) at wrapsyscall.c:77
#2 0x8132b10 in check_standard_fds () at
../sysdeps/generic/libc-start.c:110
#3 0x8132bc4 in __libc_start_main (main=0x80481d4 <main>, argc=1,
argv=0xbffffcc4,
init=0x80480b4 <_init>, fini=0x8192e48 <_fini>, rtld_fini=0,
stack_end=0xbffffcbc)
at ../sysdeps/generic/libc-start.c:60
Current language: auto; currently c
Thanks in advance.
Alex Ho <[EMAIL PROTECTED]> wrote in message
news:9f5h0s$[EMAIL PROTECTED]...
> Hi,
>
> I am using g++ version egcs-2.91.66 on Redhat 6.2. When my app is linked
> with -static, it core dumps as soon as it starts.
>
> Does anyone know why?
>
> Thanks in advance.
>
>
>
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: environment variable confusion
Date: Thu, 31 May 2001 18:44:18 GMT
[EMAIL PROTECTED] wrote:
>I'm not sure what you mean by "change the environment" here. Is the
>change done within the program-to-be-restored, or by the restorer?
The change is done in the shell before running the
program. The program runs, notices a particular command
line argument which tells it to restore itself from a prior
saved checkpoint. This technique has been used on
a solaris system and is being ported to linux
w/o much change. It does "mostly" work.
[when the program starts up, it reads a file written earlier
(prior run) to determine what memory to restore. Next 1 or
more sbrk's are done, low address dynamic memory is restored from
the file (just above the code). In
this dynamic area is a saved copy of the stack ( only a few k bytes) at
the time
the checkpoint is written, so the last part is to copy this
over top of the current stack - there is a longjmp done after this
which has been setup in such a way to get everything back
to where it was at the moment of the save, but with a jump
to the code that runs after the restore is complete. Lastly,
all i/o is reconnected. It's not a general purpose save/restore, so
we only worry about things that our program needs - I didn't write
this so I'm not 100% certain of my facts here]
So, I am guessing that bash calls setenv to create or modify
the environment inside itself, and later when you run a program,
the environment is copied out of the bash process and into the
new process that bash forked/exec'd
After looking at the code in the kernel, I see that there is a
special copy that assembles the various strings (which might
be anywhere in bash's address space) but sort of packs them
all in one place so that the program that is forked/execd ends
up with them in one contiguous spot at the top of the stack
(do I have this right?)
What I do to recreate the problem is create a variable
like this:
export XXX=aaabbb
export export XXX=abcdef_$XXX
(this last one I repeat some number of times)
So, I keep growing XXX a little bigger, and then run the
program which tries to restore itself. For a while it works,
so I make XXX bigger and try again. Eventually I get a
segment fault inside getenv (called indirectly by some timezone
library routine)
This all may seem a little fragile, but I am trying to
figure out what is going on, so I can make a policy
that will allow this to work - like don't change any
environment variables prior to a restore - but that
may not be feasible, so I need more understanding.
I do not believe that this program ever references
"environ" itself, so as a poster mentioned, the libc
.so must have some way to set this up (i guess this
is part of what the dynamic loader does although I
don't yet understand how it figures out what the
value for "environ" should be)
I was thinking I might need to have some pad space
somewhere. Maybe if I never get larger, only smaller,
it would work... I could try starting out with a large
variable and make it smaller which could give me room
to grow or add some others.
Where this all comes into play, is that it pretty much works
if I save and restore on the same system (and don't mess
with environment variables). But, for a real
robust situation, I actually need to be able to restart on
another system (as close to a clone as possible). This way
we can be running the same program at various stages
on a few processors. So, part of the problem is that
the environment of the process can be different on
the other system (host name and ip address would
be different for ex)
BTW, The program is a simulation that
can run for weeks and may use nearly 3 gigs of memory. Most of
the code resides in a .so file so we can make changes
to the program, if necessary, and then do a restart in the middle. But,
that is all working, it's only with the environment/stack
that I seem to be having trouble with now..
thanks all
eric
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Eric Taylor <[EMAIL PROTECTED]> wrote:
> >
> >
> >[EMAIL PROTECTED] wrote:
> >
> >I looked at exec.c and I see calls to copy_string, which
> >copies (i think) the environment up into kernel space. Then,
> >later, I guess it copies it back into the new process (is this
> >right?).
>
> I'm not sure of the exact sequence, but the kernel does copy it to the
> stack area of the new process.
>
> >Since environ is a pointer to an array of pointers, I take it that
> >this same procedure must re-create this pointer array. Is this
> >array also at the top of the stack, and do these 2 items (the
> >strings themselves and the pointer array) both end up at the top
> >of the stack?
>
> The kernel does this also, although I think the code is separated from
> the part copying the strings.
>
> The arrays (argv and envv) are definitely not at the top of the stack.
> (See below.)
>
> >Is there anything on the stack below this that has to point to
> >something in the environment, since my restore is failing
> >if I change the environment and then try to restore the program
> >stack.
>
> I'm not sure what you mean by "change the environment" here. Is the
> change done within the program-to-be-restored, or by the restorer?
>
>
> The restored stack must obviously be exactly aligned with its earlier
> state, since it contains variables and pointers into itself.
>
> >Are there any guard pages that might cause a segment fault
> >if I go messing around here?
>
> The kernel automatically extends the stack downward on SIGSEGV-s that
> are "sufficiently" close. I don't know what the exact rule is here,
> but you could be sure you have enough space by writing words downward
> into the stack area with a stride equal to (or smaller than) the page
> size.
>
> >And lastly, when I add an environment variable, how and who
> >determines where these go; is memory moved up/down to make room,
> >or recover room.
>
> I assume you mean something like putenv() here, i.e., a program is
> changing its own environment. If you delete a variable, the array
> entries are simply moved down to remove the dead pointer. If you add
> an entry, the entire pointer array is copied to allocated space and
> adjusted as needed. The strings themselves are not moved.
>
> If the restorer is trying to change the environment, this will get
> messy, as you can't reliably find the active pointer array, since it
> may or may not still be on the stack. Probably the only reasonably
> safe thing you could do is modify an existing string in-place, such
> that it does not grow.
>
> The following as a somewhat annotated dump of an i586 stack.
>
> envp = 0xbffffc84
> argv = 0xbffffc7c
> bffffc14 00000001 ~~~~
> bffffc18 bffffc7c |~~~
> bffffc1c bffffc84 ~~~~
> bffffc20 08048564 d~~~
> bffffc24 00000004 ~~~~
> bffffc28 bffffc48 H~~~
> bffffc2c 4003c208 ~~~@
> bffffc30 40016db4 ~m~@
> bffffc34 00000001 ~~~~
> bffffc38 08048350 P~~~
> bffffc3c bffffc7c |~~~
> bffffc40 4003c174 t~~@
> bffffc44 4012daa0 ~~~@
> bffffc48 00000000 ~~~~
> bffffc4c 08048371 q~~~
> bffffc50 08048440 @~~~
> bffffc54 00000001 ~~~~
> bffffc58 bffffc7c |~~~ **argv
> bffffc5c 080482c0 ~~~~
> bffffc60 08048564 d~~~
> bffffc64 4000d6d0 ~~~@
> bffffc68 bffffc6c l~~~
> bffffc6c 4001739c ~s~@
> bffffc70 40001fb1 ~~~@
> bffffc74 bffffc84 ~~~~ **envp
>
> Startup stack pointer seems to be here. Everything beyond here is
> set up by the kernel.
>
> bffffc78 00000001 ~~~~ argc
> bffffc7c bffffd9e ~~~~ argv[0]
> bffffc80 00000000 ~~~~
> bffffc84 bffffda5 ~~~~ envp[0] PWD=...
> bffffc88 bffffdbc ~~~~ HOSTNAME=...
> bffffc8c bffffdc9 ~~~~ MOZILLA_HOME=...
>
> [ ... ]
>
> bffffcf4 bfffffba ~~~~ LESSCHARSET=...
> bffffcf8 bfffffcd ~~~~ DEBUG_REDIRECT...
> bffffcfc bfffffe8 ~~~~ _=./dstack
> bffffd00 00000000 ~~~~
>
> The following is a set of elf-setup parameters. Some entries are
> omitted for static programs.
>
> bffffd04 00000003 ~~~~ phdr
> bffffd08 08048034 4~~~
> bffffd0c 00000004 ~~~~ phent
> bffffd10 00000020 ~~~
> bffffd14 00000005 ~~~~ phnum
> bffffd18 00000006 ~~~~
> bffffd1c 00000007 ~~~~ base
> bffffd20 40000000 ~~~@
> bffffd24 00000008 ~~~~ flags
> bffffd28 00000000 ~~~~
> bffffd2c 00000009 ~~~~ entry
> bffffd30 08048350 P~~~
> bffffd34 0000000b ~~~~ uid
> bffffd38 000003e9 ~~~~
> bffffd3c 0000000c ~~~~ euid
> bffffd40 000003e9 ~~~~
> bffffd44 0000000d ~~~~ gid
> bffffd48 00000006 ~~~~
> bffffd4c 0000000e ~~~~ egid
> bffffd50 00000006 ~~~~
> bffffd54 00000010 ~~~~ hw capabilities
> bffffd58 008001a5 ~~~~
> bffffd5c 00000006 ~~~~ page size
> bffffd60 00001000 ~~~~
> bffffd64 00000011 ~~~~ tick
> bffffd68 00000064 d~~~
> bffffd6c 0000000f ~~~~ platform (= i586)
> bffffd70 bffffd99 ~~~~
> bffffd74 00000000 ~~~~
> bffffd78 00000000 ~~~~
> bffffd7c 00000000 ~~~~
> bffffd80 00000000 ~~~~
> bffffd84 00000000 ~~~~
> bffffd88 00000000 ~~~~
> bffffd8c 00000000 ~~~~
> bffffd90 00000000 ~~~~
> bffffd94 00000000 ~~~~
> bffffd98 38356900 ~i58 (platform string)
> bffffd9c 73640036 6~ds argv strings
> bffffda0 6b636174 tack
> bffffda4 44575000 ~PWD env strings
> bffffda8 6f682f3d =/ho
> bffffdac 622f656d me/b
> bffffdb0 732f6564 de/s
> bffffdb4 6a2f6372 rc/j
> bffffdb8 006b6e75 unk~
> bffffdbc 54534f48 HOST
> bffffdc0 454d414e NAME
> bffffdc4 7868703d =phx
> bffffdc8 5a4f4d00 ~MOZ
> bffffdcc 414c4c49 ILLA
> bffffdd0 4d4f485f _HOM
>
> [ ... ]
>
> bfffffb8 454c002e .~LE
> bfffffbc 48435353 SSCH
> bfffffc0 45535241 ARSE
> bfffffc4 616c3d54 T=la
> bfffffc8 316e6974 tin1
> bfffffcc 42454400 ~DEB
> bfffffd0 525f4755 UG_R
> bfffffd4 52494445 EDIR
> bfffffd8 5f544345 ECT_
> bfffffdc 41574d58 XMWA
> bfffffe0 4e494e52 RNIN
> bfffffe4 00313d47 G=1~
> bfffffe8 2f2e3d5f _=./
> bfffffec 61747364 dsta
> bffffff0 2e006b63 ck~.
> bffffff4 7473642f /dst
> bffffff8 006b6361 ack~
> bffffffc 00000000 ~~~~
> --
> B. D. Elliott [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: How to discover File Descriptor leak in programs?
Date: Thu, 31 May 2001 18:48:21 -0000
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>We have a system with multiple processes. The system runs fine
>initially but soon runs out of File Descriptors. One of the process
>must have openned files/scokets without closing them. How do you find
>out which one is leaking File Descriptors?
Look in /proc and you'll find directories that are the same as the
pids that are in use. Under each of those is a directory called "fd".
Look there.
--
http://www.spinics.net/linux/
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
