I always get this message, when using any of the lvm2 commands. Two examples: mordor:/home/gpall# lvdisplay File descriptor 3 left open File descriptor 4 left open --- Logical volume --- LV Name /dev/evg/root VG Name evg LV UUID ttp166-h21j-D93z-GAfM-8r2s-3C9Q-uSZPla LV Write Access read/write LV Status available # open 1 LV Size 10.00 GB Current LE 2560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:1
Hi, as far as I can tell, the "File descriptor x left open" message is just telling the user about open file descriptors the lvm utility inherited and successfully closed. The --quiet option doesn't appear to suppress the message. Does printing the message serve any useful purpose? I'd expect lvcreate, lvremove and similar commands to be silent when called with --quiet; only errors should be printed. How is successfully closing a file descriptor an error? Andras
It's often an indication of a careless programming and can lead to security problems if a child process inherits access to a rogue file descriptor and can interfere with it. The messages were added during a bug investigation to prove that LVM was not involved. selinux with a strict policy now also detects this sort of bug. They can be suppressed by setting the (deliberately-undocumented) environment variable LVM_SUPPRESS_FD_WARNINGS, but really, the source of the problem you're seeing should be addressed instead of ignoring the symptoms. Alasdair
On Wed, Jul 08, 2009 at 02:21:05PM +0100, Alasdair G Kergon wrote: Hi, program should go out of its way to close any inherited file descriptor it didn't expect, and warn the user about them. Incidentally, this would make chpst -l (which relies on obtaining a lock on a file and then passing this filedescriptor on to its child, which it execs without a fork) useless. In my case, I know where the stray FD is coming from: I'm invoking lvm utilities from a zsh script that has a logging coprocess, and it does an "exec >&p" early on so that all output of any programs invoked goes to the coprocess instead of stdout. Child processes inherit a pipe to the coprocess, but this isn't a problem that needs to be addressed; it has no ill effects and certainly doesn't warrant an obnoxious warning I can only turn off by relying on an undocumented feature. I certainly agree that the warnings are a good debugging aid, but making them unnecessarily hard to turn off is, in my opinion, contrary to the unix philosophy, which entails letting the user shoot himself in the foot if he wants, and not assuming that your program is necessarily smarter than the person running it, or that the developer was able to anticipate all circumstances his or her program might be run in. I think --quiet should get rid of these warnings too; you should assume that anyone who goes out of their way to specify --quiet really does want the utility to be quiet except when critical errors occur. It's what --quiet should do, and what the documentation implies --quiet does. Anyway, thank you for the hint about LVM_SUPPRESS_FD_WARNINGS, and sorry about the ranting. Andras
Not every program, but ones that are used by root and potential targets for exploits should certainly consider it. That's perhaps one of the few valid reasons for retaining a file descriptor open, if used safely, but we've never been asked to support it. (LVM's internal locking is presumably enough.) What stops you closing the fd just before the execve()? lvm will not write to pre-existing fds other than 0, 1 & 2 and lvm is currently imposing it as a requirement that other fds, which lvm will not use, should be closed before invocation. are performed during initialisation, before even looking at any command line. Alasdair
Nothing, I suppose, other than that it adds a difficult to read line with no obvious purpose to the script (nothing a comment couldn't explain, to be sure). But I agree it's a workaround (whether it's nicer than the magic envvar, I couldn't say). I'm still not sure I understand why this is such a big deal that it's unacceptable to just close them silently, but I don't want to argue this point ad nauseam. Well, the fact that it's difficult to fix doesn't mean it's not broken. :) Currently, --quiet doesn't work properly because LVM still prints messages that aren't critical errors. I wouldn't object to this bug being downgraded to wishlist and retitled to something like "Please fix --quiet so that it suppresseses the warning about FDs left open" (it's not my bug, so I won't mess with it myself). Add a wontfix tag if you think it's never going to be fixed. However, I think at the very least the magic envvar should be documented for use in those cases where a stay FD is known to be present and LVM should be silent. This would help avoid kludges like lvsomething 2>&1 | fgrep -v ... (And hey, maybe there are even valid uses for stray FDs, only we can't think of any right now - so that not even closing them may always be desirable.) Andras
Because the cause needs investigating in case it's a security hole (or other program bug). I believe every program has a responsibility to behave defensively and report upon things it notices like that that are not normal. When you're satisfied there's not a security problem, and you don't want to change things you can choose to add the suppression. The original bug, by the way, was a system-wide file descriptor leak (not on Debian), where most processes on the system (irrespective of uid) gained unintended access to a root-only File. Currently the role of --quiet is simply to disable any pre-configured verbose or debug settings. In other words it doesn't do very much useful. But perhaps we could redefine it to suppress all the pointless "successfully" messages inherited from LVM1. In coding terms, to split the 'log_print' macro into two macros, essential output (like the data from 'lvs') and non-essential output, and have --quiet suppress the non-essential output. As I indicated, that won't get changed without significant code restructuring, which is unlikely to happen. This bug provides documentation now for anyone searching... Alasdair
I think this is the same kind of issue as in the previous report, though I'm not sure. messages like this for every lvcreate: <quote> + lvcreate -L10G -s -n _home /dev/daisy/home File descriptor 3 left open File descriptor 41 left open File descriptor 42 left open File descriptor 43 left open Logical volume "_home" created </quote> The same file descriptors are listed for each group. I do not see such messages when I do other commands such as lvs. The only installs in the previous day were of a locally built, backported (from sid--I'm on lenny) samba. These did require upgrading libpam0g, libpamruntime, libpam-modules to sid, and installing libdb4.7 from sid. I also upgraded man-db and doc-base within lenny. I think the previous discussion implies a) my lvcreate's are still working OK and b) I may have a security problem with some other program. The new installs would be the obvious suspects, particularly pam. I'm looking for confirmation of a) and advice on how to handle b). Thanks. P.S. It might also be relevant that I get a parse error from lvm every time the system starts, at something like byte 3200. I seem to have all my volumes, and I don't know where the data is that is being read.