file descriptor xx left open - problem with LVM
Bernd
i'm getting the mentioned error in SuSE Linux Enterprise Server 10 SP1
using LVM.
If i type in a xterm (under KDE) e.g. vgscan, vgdisplay, pvscan i get
the message: "file descriptor xx left open", with a one or two digit
number for xx.
Afterwards i see the desired infromations. The LV's are accessible,
reading and writing is possible. When i leave X and start a tty with
STRG+ALT+F2, and then type e.g. vgscan, vgdisplay, i don't get these
mesages !
Following questions:
1. What does these messages mean ? Are they severe ? I searched
already on the net, and found a lot of people experiencing the same
problem, but no one has a solution/explanation.
2. Why do i get these messages in a xterm, but not in a tty. In both
should run the same bash, or ?
3. How can i get more informations about these file descriptors ? E.g.
which process is attached, or which file is it in real ?
Thanks in advance for any help.
Bernd
Dances With Crows
> If i type [vgscan, vgdisplay, [or] pvscan] in a xterm[,] i get "file
> descriptor xx left open", with a one or two digit number for xx.
> reading and writing is possible. When i leave X and start a tty with
> message].
> What [do] these messages mean? Are they severe? I searched already on
> the net, and found a lot of people experiencing the same problem, but
> no one has a solution/explanation.
This sounds like a bug in SuSE. SuSE has always had a bunch of bugs in
it, IME many more than Debian or Gentoo. That, the better package
management available on Debian/Gentoo, and the craptastic SuSE 8.0 drove
me away from SuSE years and years ago.
> Why do i get these messages in a xterm, but not in a [virtual
> console?] [bash] should run [in both], [right]?
This is strange. From a recent lvm2 source tarball, the function that
produces this error message is one of the very first functions that gets
called, and it closes every fd except stdin, stdout, and stderr. xterm
is not a VC, and the bug might be in xterm. Or maybe the bash you're
running in the xterm was started with different options than the bash
you're running from the VC. That shouldn't really affect anything
though.
> How can i get more [information] about these file descriptors? Which
> process is attached, or which file is [attached to that descriptor]?
The most sure way is to use strace. "strace -ff xterm", then in the
newly opened xterm, "pvscan", then exit the xterm. Then eyeball-grep
through the files that strace wrote out for things that are out of the
ordinary. It might be better to do "strace -eopen,close -ff xterm"
because that will give you less junk to grep through. Check the man
page for strace for what those options do. HTH anyway,
--
The early bird who catches the worm works for someone who comes in
late and owns the worm farm. --Travis McGee
My blog and resume: http://crow202.dyndns.org:8080/wordpress/
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Bernd
> Bernd staggered into the Black Sun and said:
>
>
> This sounds like a bug in SuSE. SuSE has always had a bunch of bugs in
> it, IME many more than Debian or Gentoo. That, the better package
> management available on Debian/Gentoo, and the craptastic SuSE 8.0 drove
> me away from SuSE years and years ago.
>
I have to live with SLES, beacause they support all my hardware on my
ProLiant-systems.
And otherwise i don't get support from HP. :-(
> This is strange. From a recent lvm2 source tarball, the function that
> produces this error message is one of the very first functions that gets
> called, and it closes every fd except stdin, stdout, and stderr. xterm
> is not a VC, and the bug might be in xterm. Or maybe the bash you're
> running in the xterm was started with different options than the bash
> you're running from the VC. That shouldn't really affect anything
> though.
In a konsole (it was a konsole, not an xterm, sorry), i compared the
options with which bash has been
started (echo $*) with the options bash is started in a vc. They were
they same. No option in both cases.
>
> The most sure way is to use strace. "strace -ff xterm", then in the
> newly opened xterm, "pvscan", then exit the xterm. Then eyeball-grep
> through the files that strace wrote out for things that are out of the
> ordinary. It might be better to do "strace -eopen,close -ff xterm"
> because that will give you less junk to grep through. Check the man
> page for strace for what those options do. HTH anyway,
>
Puuuh, strace is very powerful and verbose.
I found out the following:
excerpt from strace in a vc:
------
6117 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
6117 close(3) = -1 EBADF (Bad file
descriptor)
6117 close(4) = -1 EBADF (Bad file
descriptor)
6117 close(5) = -1 EBADF (Bad file
descriptor)
6117 close(6) = -1 EBADF (Bad file
descriptor)
6117 close(7) = -1 EBADF (Bad file
descriptor)
6117 close(8) = -1 EBADF (Bad file
descriptor)
6117 close(9) = -1 EBADF (Bad file
descriptor)
6117 close(10) = -1 EBADF (Bad file
descriptor)
6117 close(11) = -1 EBADF (Bad file
descriptor)
6117 close(12) = -1 EBADF (Bad file
descriptor)
6117 close(13) = -1 EBADF (Bad file
descriptor)
6117 close(14) = -1 EBADF (Bad file
descriptor)
...
------
this continues to close(1023). I think that pvscan here closes all fd
from 3 to 1023.
The result is always -1, beacuse there are no files to close. Right ?
Now the same pvscan in a konsole (excerpt):
-------
22423 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
22423 close(3) = -1 EBADF (Bad file
descriptor)
22423 close(4) = 0
22423 write(2, "File descriptor 4 left open\n", 28) = 28
22423 close(5) = -1 EBADF (Bad file
descriptor)
22423 close(6) = -1 EBADF (Bad file
descriptor)
22423 close(7) = -1 EBADF (Bad file
descriptor)
22423 close(8) = -1 EBADF (Bad file
descriptor)
22423 close(9) = -1 EBADF (Bad file
descriptor)
22423 close(10) = 0
22423 write(2, "File descriptor 10 left open\n", 29) = 29
22423 close(11) = -1 EBADF (Bad file
descriptor)
22423 close(12) = -1 EBADF (Bad file
descriptor)
...
---------
Here pvscan also closes fd's from 3 to 1023.
But some are open, so the closing is successfull (return value = 0).
So pvscan blames about not properly closed fd's "write(2, "File
descriptor 4 left open\n", 28)"
Right ?
So, in my eyes, xterm and konsole open a lot of fd's (they really do a
lot of stuff, strace proves it), but don't close them all.
pvscan (and probably all other tools like vgscan, vgdisplay,
lvscan ...) try to close all fd's to 1023 (for security reasons ?), if
they have been opened before or not. Right ?
It's surprising how much xterm and konsole do, i'm very astonished.
Bernd
BTW: it's sad that there is so much advertisment in this group. That's
really not funny, and you are searching hard for "real" postings.
Does google not have have the possibility to block that ? In email,
today there are solutions which really filter most of the spam.
If this advertisment continues, this group will loose its sense.
Dances With Crows
>> This sounds like a bug in SuSE. SuSE has always had a bunch of bugs
>> in it, IME many more than Debian or Gentoo.
> ProLiant-systems. And otherwise i don't get support from HP. :-(
Do you *need* that "support"? Most of the time, when you buy good
hardware, it keeps running for years and years.
>> From a recent lvm2 source tarball, the function that produces this
>> error message is one of the very first functions that gets called,
>> and it closes every fd except stdin, stdout, and stderr. xterm is
>> not a VC, and the bug might be in xterm.
> In a konsole (it was a konsole, not an xterm, sorry), i compared the
> options with which bash has been started (echo $*) with the options
> bash is started in a vc. They were they same. No option in both cases.
OK, it's not a bash problem, but probably a konsole problem. I've done
almost all of my lvm2 commands from a konsole and never seen the
"unclosed file descriptor" message.
>> The most sure way is to use strace.
> 6117 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
> 6117 close(3) = -1 EBADF (Bad file
> this continues to close(1023). I think that pvscan here closes all fd
> from 3 to 1023. The result is always -1, beacuse there are no files
> to close. Right ?
Yes.
> Now the same pvscan in a konsole (excerpt):
> 22423 close(3) = -1 EBADF (Bad file
> 22423 close(4) = 0
> 22423 write(2, "File descriptor 4 left open\n", 28) = 28
> 22423 close(10) = 0
> 22423 write(2, "File descriptor 10 left open\n", 29) = 29
> But some are open, so the closing is successfull (return value = 0).
> So pvscan [complains] about not properly closed fd's "write(2, "File
> descriptor 4 left open\n", 28)" Right?
Yes. When a process fork()s, it inherits open file descriptors from its
parent. The lvm2 toolset tries to close() all of them except stdin,
stdout, and stderr. This is either for security reasons or because
some operations may require the tools to open a ton of files.
> So, in my eyes, konsole [opens] a lot of fd's but [doesn't] close them
> all.
It's strange that your konsole is doing this. Does the same thing
happen in an xterm? If not, it's probably a konsole bug. If so, it's
something more pervasive and weird.
> BTW: it's sad that there is so much advertisment in this group. Does
> google not have have the [ability] to block that?
They have the ability. The fact that they haven't *used* it
demonstrates that they are not interested in dealing with Usenet spam.
You have an alternative; news.individual.net at 10 Euros/year and a real
NNTP client. They do a good job of filtering out the crap. They're
even located in .de .
> If this [spam] continues, this group will [lose] its [value].
Yes. Experienced people know how to deal, newbies have no clue. (One
of many reasons why Usenet is fading away and web forums are picking up
more users....)
--
"Cheer up, things could be worse." So I cheered up, and sure enough,
things got worse.
Bernd
>
> Do you *need* that "support"? Most of the time, when you buy good
> hardware, it keeps running for years and years.
Yes. Not with the hardware itself, more with special HP-Software:
System Insight Manager, System Management Homepage.
I tried another OS (e.g. OpenSuSE), but didn't suceed in installing.
>
>
This happens also in a xterm.
What else can i do to track down the problem ?
Are open fd's a severe problem ? Now, as i understand a bit more about
that problem, i feel already a less better.
In a certain way, this message is positive. If pvscan didn't try to
close the fd's from 3 to 1023, they would been left open. Why does
pvscan begins with 3 ? Because 0,1 and 2 are for stout, stdin and
sterr ?
Bernd
Dances With Crows
>> hardware, it keeps running for years and years.
> Yes. Not with the hardware itself, more with special HP-Software:
> System Insight Manager, System Management Homepage. I tried another
> OS (e.g. OpenSuSE), but didn't suceed in installing.
If software is not a package manager, and that software won't work
unless distro N is installed, that software is BROKEN. It's possible
(though it's a pain) to install and use *Oracle* on "non-approved"
distros. Oracle is at least an order of magnitude more complex than the
things you mentioned.
>>> So, in my eyes, konsole [opens] a lot of fd's but [doesn't] close
>>> them all.
>> It's strange that your konsole is doing this. Does the same thing
>> happen in an xterm?
> This [also happens] in [an] xterm. What else can I do to track down
> the problem?
The only things that konsole and xterm have in common are some base X11
libs, libc, libm, libdl, libfontconfig, libfreetype, libz, and libxml2.
This is very strange. One other thing to try might be to log in to X
using a different WM or DE instead of your default, then see if you get
the same error. I don't *think* KDE or GNOME would be doing odd things
to running processes' file descriptors, but ICBW.
> Are open fds a severe problem? Now, as I understand a bit more about
> that problem, I feel [less good].
lvm2 is warning you, not barfing. Important system tools like lvm2 are
often very paranoid about everything, even minor problems, for obvious
reasons. You can "export LVM_SUPPRESS_FD_WARNINGS=1" in /etc/profile to
prevent it from warning you if you want.
> Why does pvscan [begin] with 3? Because 0,1 and 2 are for [stdout], stdin
> and [stderr]?
Yes. By default, stdin is fd 0, stdout is fd 1, and stderr is fd 2.
You've probably seen "2>&1" at the end of bash command lines. This
redirects stderr to stdout, which can be useful sometimes.
--
You have me mixed up with more creative ways of being stupid.
--MegaHAL, trained on random gibberish
Bernd
> Bernd staggered into the Black Sun and said:
> The only things that konsole and xterm have in common are some base X11
> libs, libc, libm, libdl, libfontconfig, libfreetype, libz, and libxml2.
> This is very strange. One other thing to try might be to log in to X
> using a different WM or DE instead of your default, then see if you get
> the same error. I don't *think* KDE or GNOME would be doing odd things
> to running processes' file descriptors, but ICBW.
>
I tested pvscan, vgscan ... under FVWM.
With that wm i didn't get the message.
With twm i got one fd open, another number as in KDE.
> lvm2 is warning you, not barfing. Important system tools like lvm2 are
> often very paranoid about everything, even minor problems, for obvious
> reasons. You can "export LVM_SUPPRESS_FD_WARNINGS=1" in /etc/profile to
> prevent it from warning you if you want.
>
Are open fd's something severe ?
Of course, it's not good software writing.
But i think i have these open fd's, if i use LVM or not. LVM just
informs about them.
So, in a certain way, LVM is helpful for that problem, because it
closes fd's in this range (3-1023) which
would been open otherwise.
I think i can live with that. For me it's not as severe as in the
past, because i know now from where the message comes and what it
means.
Do you agree ?
Bernd
Dances With Crows
>> This is very strange. One other thing to try might be to log in to X
>> using a different WM or DE instead of your default, then see if you
>> get the same error. I don't *think* KDE or GNOME would be doing odd
>> things to running processes' file descriptors, but ICBW.
> I tested pvscan, vgscan ... under FVWM. With that wm i didn't get the
> message. With twm i got one fd open, another number as in KDE.
Great, a problem that's WM-dependent. I'm not sure how you'd go about
debugging this one without a lot of time and effort. A start might be
"what does twm do/use that fvwm doesn't do/use?"
>> Important system tools like lvm2 are often very paranoid about
>> everything, even minor problems, for obvious reasons. You can
>> "export LVM_SUPPRESS_FD_WARNINGS=1" in /etc/profile to prevent it
>> from warning you if you want.
> Are open fd's something severe?
In this case, no.
> But i think i have these open fd's, if i use LVM or not. LVM just
> informs about them. I think i can live with that. For me it's not as
> severe as in the past, because i know now from where the message comes
> and what it means. Do you agree ?
I don't think this is a serious problem, but it points out that
something is not completely kosher within the WMs and DEs in the distro
you're using.
--
I think I'll have to put on 500 pounds of subwoofers, amps, and other
delicious herbs. --MegaHAL, trained on ASR
Bernd
Hey,
i will not longer follow this message because i can live with that. I
don't have the time and the energy at the moment. I thank you very
much for your support and ideas. Have a nice week.
Bernd