ssh-sftp-perl-users

RE: [Ssh-sftp-perl-users] Net::SFTP Patch

[David R. <dr...@at...>]

> From: ssh...@li...
> [mailto:ssh...@li...]On Behalf Of
> Robert Landrum
> Sent: Wednesday, December 22, 2004 11:10 AM
> Subject: [Ssh-sftp-perl-users] Net::SFTP Patch
>=20
> It came to my attention that Bricolage which uses Net::SFTP=20
> was leaving sshd connections open.  The Bric dev guys were doing a =
undef=20
> $sftp; to close the connection, but that wasn't sufficient to close =
the=20
> connection.  And with apache not exiting at the end of the request =
cycle to force the=20
> connection closed, our server quickly ran out of open file handles.

undef'ing the object works fine for me - would you happen to be using a =
version of perl earlier than 5.6?  I know with 5.005003 it's easy to =
leak handles.

> I've added a close_connection method to the Net::SFTP module, and =
thought
> that others might have use for such a method.  I also added a DESTROY
> method, which I don't think necessarily belongs, but which I added =
just
> so I wouldn't have to muck with the Bric code too...

I'm not the maintainer, but it might be preferable to find out why =
undef'ing fails before adding code.

Ideally undef'ing drops the refcount to zero, which destroys the =
Net::SFTP object, which cascades to the Net::SSH::Perl and its =
sub-objects and eventually the socket is closed.

> Robert Landrum
> Systems Programmer

--=20
Dave
Isa. 40:31

RE: [Ssh-sftp-perl-users] Net::SFTP Patch

[David R. <dr...@at...>]

> From: ssh...@li...
> [mailto:ssh...@li...]On Behalf Of
> Robert Landrum
> Sent: Wednesday, December 22, 2004 2:49 PM
> Subject: Re: [Ssh-sftp-perl-users] Net::SFTP Patch
>=20
> > Ideally undef'ing drops the refcount to zero, which=20
> destroys the Net::SFTP object, which cascades to the=20
> Net::SSH::Perl and its sub-objects and eventually the socket=20
> is closed.
>=20
> The refcount doesn't reach zero.  Because Socket is used, and because
> Socket does the gensym call, the reference created from the resulting =
file
> handle, when collected, doesn't release the symbol.  As I recall, it =
has=20
> something to due with scope, but my memory is hazy. All this=20
> is done within Net::SSH::Perl.  An explicit close needs to be called =
on the=20
> filehandle (which I don't think is happening) in order for it to=20
> correctly close the socket because apache/mod_perl process will never =
(or rarely)=20
> garbage collect it.

Are you using the latest Net::SSH::Perl (or at least a version >=3D =
1.24)?

In the version I have (1.25) there's a _create_socket that calls gensym =
directly.

This quick test shows there's nothing innate about gensyms that stops =
them from being destroyed when they go out of scope:

  perl -MSymbol -wle '{sub Foo::DESTROY { print "DESTROY" } my =
$a=3Dgensym; bless $a, "Foo";} print "OUTER"'

prints "DESTROY" and then "OUTER" as expected.

Since perl does refcounted g/c, it's either yes or no; I don't think =
"rarely" is an option, as it might be for Java, which uses its own =
heuristics to decide when to g/c and isn't refcount based.

> Robert Landrum
> Systems Programmer

--=20
Dave
Isa. 40:31

Re: [Ssh-sftp-perl-users] Net::SFTP Patch

[Robert L. <rla...@ao...>]

On Wed, Dec 22, 2004 at 12:57:29PM -0500, David Robins wrote:
> undef'ing the object works fine for me - would you happen to be using a version of perl earlier than 5.6?  I know with 5.005003 it's easy to leak handles.
> 

From a perl script it should work fine.  From mod_perl, it doesn't.  We're
using 5.6.1.

> I'm not the maintainer, but it might be preferable to find out why undef'ing fails before adding code.
> 
> Ideally undef'ing drops the refcount to zero, which destroys the Net::SFTP object, which cascades to the Net::SSH::Perl and its sub-objects and eventually the socket is closed.
> 

The refcount doesn't reach zero.  Because Socket is used, and because
Socket does the gensym call, the reference created from the resulting file
handle, when collected, doesn't release the symbol.  As I recall, it has 
something to due with scope, but my memory is hazy. All this is done within
Net::SSH::Perl.  An explicit close needs to be called on the filehandle
(which I don't think is happening) in order for it to correctly close the
socket because apache/mod_perl process will never (or rarely) garbage collect
it.

At least that's my theory.

Rob

-- 
Robert Landrum
Systems Programmer