From grant at mclean.net.nz Tue Apr 5 02:51:47 2011 From: grant at mclean.net.nz (Grant McLean) Date: Tue, 05 Apr 2011 21:51:47 +1200 Subject: [Wellington-pm] Meeting in 1 week Message-ID: <1301997107.2410.30.camel@hoiho> Hi Mongers The April meeting of Wellington Perl Mongers is next Tuesday (the 12th). We have two talks lined up: * Matthew Gray - Dist::Zilla * Sam Vilain - developing Perl wrappers for C libraries See you there Grant From grant at mclean.net.nz Sun Apr 10 14:28:52 2011 From: grant at mclean.net.nz (Grant McLean) Date: Mon, 11 Apr 2011 09:28:52 +1200 Subject: [Wellington-pm] Meeting tomorrow night Message-ID: <1302470932.12121.1.camel@putnam> Hi Mongers The April meeting of Wellington Perl Mongers is tomorrow evening (April 12th). We have two speakers scheduled: * Matthew Gray - Dist::Zilla * Sam Vilain - developing Perl wrappers for C libraries See you there Grant From grant at mclean.net.nz Thu Apr 14 02:31:33 2011 From: grant at mclean.net.nz (Grant McLean) Date: Thu, 14 Apr 2011 21:31:33 +1200 Subject: [Wellington-pm] Roundup of this week's meeting Message-ID: <1302773493.2798.6.camel@hoiho> Hi Mongers Thank you to Matthew and Sam for a couple of interesting talks on Tuesday night. I have been finding Dist::Zilla to be useful, but must admit I haven't yet plucked up the courage to dive into XS. The slides are up on the web site archive page: http://wellington.pm.org/archive/ As I mentioned, Matthew has offered to speak again(!) next month on the subject of Mason 2. That leaves room for one more talk (or two short ones) let me know if you'd like to book a slot. And Donovan is working on putting together his geek quiz for the June meeting. See you on May 10th. Grant From richard at walnut.gen.nz Tue Apr 19 03:01:21 2011 From: richard at walnut.gen.nz (Richard Hector) Date: Tue, 19 Apr 2011 22:01:21 +1200 Subject: [Wellington-pm] question about 'system', and other methods for calling os functions Message-ID: <1303207281.9754.11.camel@topaz.wgtn.cat-it.co.nz> Hi all, I'm trying to call 'lvcreate' to create a logical volume on a linux system. Apparently, all lvm commands are sensitive to how many filehandles they have, and it appears that perl creates 3 extra ones (DATA, ARGV and ARGVOUT), which get passed through and cause warnings: File descriptor 5 (socket:[16653008]) leaked on lvcreate invocation. Parent PID 18226: /usr/bin/perl File descriptor 6 (pipe:[16653009]) leaked on lvcreate invocation. Parent PID 18226: /usr/bin/perl File descriptor 7 (pipe:[16653009]) leaked on lvcreate invocation. Parent PID 18226: /usr/bin/perl Can anybody suggest how to call an external function in such a way that those extra handles are not visible? I've tried forking, then closing them in the child before calling system (I know that means 2 forks; if it had worked I'd have looked at exec instead), but get the same result. Many thanks, Richard From perl at ewen.mcneill.gen.nz Tue Apr 19 03:37:33 2011 From: perl at ewen.mcneill.gen.nz (Ewen McNeill) Date: Tue, 19 Apr 2011 22:37:33 +1200 Subject: [Wellington-pm] question about 'system', and other methods for calling os functions In-Reply-To: <1303207281.9754.11.camel@topaz.wgtn.cat-it.co.nz> References: <1303207281.9754.11.camel@topaz.wgtn.cat-it.co.nz> Message-ID: <4DAD65ED.3040704@ewen.mcneill.gen.nz> On 2011-04-19 22:01 , Richard Hector wrote: > Can anybody suggest how to call an external function in such a way that > those extra handles are not visible? > > I've tried forking, then closing them in the child before calling system > (I know that means 2 forks; if it had worked I'd have looked at exec > instead), but get the same result. I'd expect fork()/exec()/waitpid(), in such a way that a shell doesn't get invoked, to be the most reliable way of having low level control over what environment/file handles/etc is passed to the underlying program. The perl fork()/exec() fairly closely mirrors the underlying C library. (A system() call, particularly one with shell syntax in the command line passed to it (including a single string with spaces) will generally be run via a shell, which will do its own thing with the environment/file handles/etc.) You may be able to explicitly set the (unix) FD_CLOEXEC flag on the relevant file descriptors before the system() call (which should be doing fork()/exec()/other stuff under the hood on a Linux system), sort of like the reverse of the example towards the end of this page: http://aaroncrane.co.uk/talks/pipes_and_processes/ but I'm not sure it's worth the effort. That said, I'm unable to find a combination of perl+LVM tools amongst, eg, my Debian systems that reproduces that behaviour with: sudo perl -e 'system("lvdisplay");' sudo perl -e 'system("lvcreate");' so possibly the versions on those systems have been fixed not to issue a warning (it's basically a debug warning), or otherwise handle things in a more graceful fashion. Or possibly a more involved Perl program is required to trigger the behaviour. (I note an obvious lack of source snippets, or specific version information, in the original message...) Ewen PS: Depending on your use case, various kludges to just hide the warning messages may be appropriate. From perl at ewen.mcneill.gen.nz Tue Apr 19 03:46:29 2011 From: perl at ewen.mcneill.gen.nz (Ewen McNeill) Date: Tue, 19 Apr 2011 22:46:29 +1200 Subject: [Wellington-pm] question about 'system', and other methods for calling os functions In-Reply-To: <4DAD65ED.3040704@ewen.mcneill.gen.nz> References: <1303207281.9754.11.camel@topaz.wgtn.cat-it.co.nz> <4DAD65ED.3040704@ewen.mcneill.gen.nz> Message-ID: <4DAD6805.6080504@ewen.mcneill.gen.nz> On 2011-04-19 22:37 , Ewen McNeill wrote: > PS: Depending on your use case, various kludges to just hide the warning > messages may be appropriate. Including, perhaps, the "I know, I know, don't tell me" magic environment variable: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138#15 assuming you don't care about the "could be a security issue if the wrong thing were leaked" issue in your context. Ewen From richard at walnut.gen.nz Tue Apr 19 17:14:09 2011 From: richard at walnut.gen.nz (Richard Hector) Date: Wed, 20 Apr 2011 12:14:09 +1200 Subject: [Wellington-pm] question about 'system', and other methods for calling os functions In-Reply-To: <4DAD65ED.3040704@ewen.mcneill.gen.nz> References: <1303207281.9754.11.camel@topaz.wgtn.cat-it.co.nz> <4DAD65ED.3040704@ewen.mcneill.gen.nz> Message-ID: <1303258449.6766.6.camel@topaz.wgtn.cat-it.co.nz> On Tue, 2011-04-19 at 22:37 +1200, Ewen McNeill wrote: > You may be able to explicitly set the (unix) FD_CLOEXEC flag on the > relevant file descriptors before the system() call (which should be > doing fork()/exec()/other stuff under the hood on a Linux system), sort > of like the reverse of the example towards the end of this page: > > http://aaroncrane.co.uk/talks/pipes_and_processes/ > > but I'm not sure it's worth the effort. Yes, I found that (FD_CLOEXEC, not the link) last night, and was planning to try it ... > That said, I'm unable to find a combination of perl+LVM tools amongst, > eg, my Debian systems that reproduces that behaviour with: > > sudo perl -e 'system("lvdisplay");' > sudo perl -e 'system("lvcreate");' ... but I figured I'd play with reproducing it in a smaller program, and eventually managed by adding the line: my $vmm = Sys::Virt->new(uri => "qemu:///system"); Sys::Virt is an XS wrapper around libvirt, for managing various types of virtual machines on linux. So I guess it's opening the extra filehandles - which may well not be the ones I mentioned earlier. I don't like the idea of hiding warnings, so I guess I need to re-order the code (so it creates the lvs before calling Sys::Virt), or confirm which filehandles they are and close them in a separate process with FD_CLOEXEC. Or something. Any tips on identifying open filehandles? Google wasn't too helpful on that :-( Thanks, Richard