leaked on lvscan invocation
Geoff Clements
what the problem is (google didn't help)
# lvscan
File descriptor 4 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 9 (socket:[44871]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 10 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 11 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 12 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 13 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 14 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 15 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 16 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 17 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 18 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 19 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 20 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 21 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 22 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 23 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 24 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 25 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 26 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 27 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 28 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 29 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 30 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 31 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 32 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 33 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
File descriptor 34 (socket:[44604]) leaked on lvscan invocation. Parent PID
10610: bash
ACTIVE '/dev/scotty/root' [600.00 MB] inherit
ACTIVE '/dev/scotty/home' [400.47 GB] inherit
ACTIVE '/dev/scotty/tmp' [348.00 MB] inherit
ACTIVE '/dev/scotty/usr' [18.31 GB] inherit
ACTIVE '/dev/scotty/var' [2.61 GB] inherit
ACTIVE '/dev/scotty/swap' [18.62 GB] inherit
--
Geoff
Nix
> I use lvm and I've just started seeing these messages, anyone got any idea
> what the problem is (google didn't help)
>
> # lvscan
> File descriptor 4 (socket:[44604]) leaked on lvscan invocation. Parent PID
> 10610: bash
From the manpage:
,----[ lvm(8) ]
| On invocation, lvm requires that only the standard file descriptors
| stdin, stdout and stderr are available. If others are found, they
| get closed and messages are issued warning about the leak.
`----
It's warning of a possible bug in *bash*, i.e. that it left file
descriptors other than the standard three open across invocation.
I'm not sure why it cares, though: most programs just silently
close them...
Geoff Clements
> On 5 Jul 2009, Geoff Clements stated:
>
>> I use lvm and I've just started seeing these messages, anyone got any
>> idea what the problem is (google didn't help)
>>
>> # lvscan
>> File descriptor 4 (socket:[44604]) leaked on lvscan invocation. Parent
>> PID 10610: bash
>
> From the manpage:
>
> ,----[ lvm(8) ]
> | On invocation, lvm requires that only the standard file descriptors
> | stdin, stdout and stderr are available. If others are found, they
> | get closed and messages are issued warning about the leak.
> `----
>
mmm - it may be on your man page it's not on mine.
lvm> version
LVM version: 2.02.44 (2009-01-26)
Library version: 1.02.30 (2009-01-26)
Driver version: 4.13.0
> It's warning of a possible bug in *bash*, i.e. that it left file
> descriptors other than the standard three open across invocation.
>
> I'm not sure why it cares, though: most programs just silently
> close them...
Thank-you nix - I can safely ignore.
--
Geoff
Richard Kettlewell
> From the manpage:
>
> ,----[ lvm(8) ]
> | On invocation, lvm requires that only the standard file descriptors
> | stdin, stdout and stderr are available. If others are found, they
> | get closed and messages are issued warning about the leak.
> `----
That's a bizarre thing to warn about.
> It's warning of a possible bug in *bash*, i.e. that it left file
> descriptors other than the standard three open across invocation.
Why would anyone think that was a bug? If you 'exec 3>/tmp/spong'
then you'd expect that to still be available as FD 3 in children.
> I'm not sure why it cares, though: most programs just silently
> close them...
I suspect in fact most programs completely ignore them.
Nix
> Nix wrote:
>> ,----[ lvm(8) ]
>> | On invocation, lvm requires that only the standard file descriptors
>> | stdin, stdout and stderr are available. If others are found, they
>> | get closed and messages are issued warning about the leak.
>> `----
>>
>
> mmm - it may be on your man page it's not on mine.
> lvm> version
> LVM version: 2.02.44 (2009-01-26)
Looking at the git logs, the message was added in 2.02.45.
Nix
> Nix <nix-ra...@esperi.org.uk> writes:
>
>> From the manpage:
>>
>> ,----[ lvm(8) ]
>> | On invocation, lvm requires that only the standard file descriptors
>> | stdin, stdout and stderr are available. If others are found, they
>> | get closed and messages are issued warning about the leak.
>> `----
>
> That's a bizarre thing to warn about.
It was added waay back in 2004, in 2.00.30. It is unclear to me why
it gives a damn.
>> It's warning of a possible bug in *bash*, i.e. that it left file
>> descriptors other than the standard three open across invocation.
>
> Why would anyone think that was a bug? If you 'exec 3>/tmp/spong'
> then you'd expect that to still be available as FD 3 in children.
Yep. Perhaps Alasdair found a circumstance in which this could cause
deadlocks? LVM is unusual in that a lot of things it can do involve
suspension of disk I/O for a period, during which writers to those
devices are blocked (indeed LVM has known bugs in this area involving
snapshotting the root filesystem). But I wouldn't expect LVM to write to
a stray fd anyway, and you can trigger any such deadlock with stdout
just as easily.
So, no, I can't figure out why.
>> I'm not sure why it cares, though: most programs just silently
>> close them...
>
> I suspect in fact most programs completely ignore them.
True. I was thinking 'setuid daemons', really, which of course lvm is
not.
Richard Kettlewell
> Richard Kettlewell stated:
>> Nix <nix-ra...@esperi.org.uk> writes:
>>> It's warning of a possible bug in *bash*, i.e. that it left file
>>> descriptors other than the standard three open across invocation.
>>
>> Why would anyone think that was a bug? If you 'exec 3>/tmp/spong'
>> then you'd expect that to still be available as FD 3 in children.
>
> Yep. Perhaps Alasdair found a circumstance in which this could cause
> deadlocks? LVM is unusual in that a lot of things it can do involve
> suspension of disk I/O for a period, during which writers to those
> devices are blocked (indeed LVM has known bugs in this area involving
> snapshotting the root filesystem). But I wouldn't expect LVM to write to
> a stray fd anyway, and you can trigger any such deadlock with stdout
> just as easily.
>
> So, no, I can't figure out why.
Closing them seems fair enough, if a little odd in context. If nothing
else it reduces the chance of EMFILE a little.
It's logging the close that seems weird.
>>> I'm not sure why it cares, though: most programs just silently
>>> close them...
>>
>> I suspect in fact most programs completely ignore them.
>
> True. I was thinking 'setuid daemons', really, which of course lvm is
> not.
Tangentially: can you _guarantee_ to close all FDs above 2, without
(i) closing all the way up to INT_MAX [which might take unreasonably
long] (ii) grobbling in /proc/self/fd [which might not be there]?
Nix
news server: I'd have left by now if I could get a MAC, but they've
screwed up so badly I can't even do that. My DNS is dead and email
is all bouncing, what joy.]
getrlimit (RLIMIT_NOFILE, ...) followed by a giant heap of closes is
the only other portable option. It too is hardly optimal.
Richard Kettlewell
> On 13 Jul 2009, Richard Kettlewell said:
>> Tangentially: can you _guarantee_ to close all FDs above 2, without
>> (i) closing all the way up to INT_MAX [which might take unreasonably
>> long] (ii) grobbling in /proc/self/fd [which might not be there]?
>
> getrlimit (RLIMIT_NOFILE, ...) followed by a giant heap of closes is
> the only other portable option. It too is hardly optimal.
Unfortunately it also doesn't work. (Which is why I asked l-)
$ cat t.c
#include <stdlib.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/resource.h>
static void fatal(const char *s) { perror(s); exit(1); }
int main(int argc, char **argv) {
struct rlimit rl[1];
if(dup2(0, 128) < 0) fatal("dup2");
rl->rlim_cur = 64;
rl->rlim_max = 64;
if(setrlimit(RLIMIT_NOFILE, rl) < 0) fatal("setrlimit RLIMIT_NOFILE");
execvp(argv[1], argv + 1); fatal("execvp");
}
$ gcc -o t t.c
$ ./t sh -c 'ulimit -Sn;ulimit -Hn;lsof -p $$'
64
64
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sh 1339 rjk cwd DIR 254,0 4096 4374530 /home/rjk
sh 1339 rjk rtd DIR 254,0 4096 2 /
sh 1339 rjk txt REG 254,0 797784 4472834 /bin/bash
sh 1339 rjk mem REG 254,0 8513977 3238249 /usr/lib/debug/libc-2.7.so
sh 1339 rjk mem REG 254,0 102614 3238253 /usr/lib/debug/libdl-2.7.so
sh 1339 rjk mem REG 254,0 256288 3383341 /lib/libncurses.so.5.7
sh 1339 rjk mem REG 254,0 119288 3383318 /lib/ld-2.7.so
sh 1339 rjk mem REG 254,0 1282800 3122658 /usr/lib/locale/locale-archive
sh 1339 rjk mem REG 254,0 25700 3105143 /usr/lib/gconv/gconv-modules.cache
sh 1339 rjk 0u CHR 136,16 18 /dev/pts/16
sh 1339 rjk 1u CHR 136,16 18 /dev/pts/16
sh 1339 rjk 2u CHR 136,16 18 /dev/pts/16
sh 1339 rjk 128u CHR 136,16 18 /dev/pts/16