Giters

johnae / sambal

Ruby Samba Client

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

close doesn't finish smbclient process

vtamara opened this issue · comments

commented

In a rails application where I use sambal, after transferring a file and closing connection I see smbclient processes running.

I'm using OpenBSD/adJ 5.6 on amd64 with ruby 2.2.2, samba-3.6.15p14 and latest sambal.

I could replicate the problem with the following program:

require 'sambal'

client = Sambal::Client.new(domain: 'WORKGROUP', host: '192.168.10.40', share: 'MyShare$', user: 'myuser', password: 'mypassword', port: 445)
client.get("V92/1000/503798.TIF", "y.tif")
puts client.ls
client.close

while true do
end

Before running in a terminal I see:

$ ps ax | grep smb
28413 pa  R+      0:00.00 grep smb

While it runs but after client.close I see:

$ ps ax | grep smb                    
17938 p9  Ss+     0:00.07 sh -c smbclient //192.168.10.40/MyShare$ mypassword -W WORKGROUP -U myuser -p 445
29222 p9  S+      0:00.01 smbclient //192.168.10.40/MyShare$ mypassword -W WORKGROUP -U myuser -p 445
 5367 pa  R+      0:00.00 grep smb

I was able to fix. God's wanting I'll send pull request.

commented

Thank you. Sorry, haven't been very active in this repo for a long time.

commented

I noticed that the solution I proposed has a problem because it leaves a zombie process.

After running the test that I posted before I see something like:

$ ps ax | grep sh
....
1357 pa- Z 0:00.00 (sh)

I found a solution, and wish to send a pull request shortly.

commented

Thanks for merging #9

commented

@johnae Could you make a release with this fix? We're running into this in production. Until then, I'll point at the commit.

Thanks!

commented

@will-in-wi I'm fairly certain 0.1.7 which was released on january 19th includes this. Are you saying it's still an issue?

commented

I just realized that it was indeed released. Yes, this is still an issue. I'm running the latest commit from master on a CentOS 6 box, and the commands hang around after the process is finished.

I'm looking into it…

commented

Turns out that our issue is that we never call Sambal::Client#close. I made the mistake of assuming automatic resource cleanup.

commented

Aha I see. I guess that could be implemented, though it should be quite easy to wrap up from outside too. I always considered this to be more of a low-level library. But, as with File, it could be done in using blocks I suppose.

commented

I thought about that for a while, and I'm fine either way. Having block syntax would probably be good and remind consumers of the API that they need to clean up if they don't use the syntax.

Another option I looked into was the usage of finalizers, so that it would be closed on GC. However, in our infrequent access server case (Rails under Passenger), GC didn't run often enough to make a difference (or at least not enough to not annoy our server admins).

The part that I found unexpected is that it seems possible (untested) to instantiate the class (which opens a connection), call close, and then call other methods on it, which it seems would break since the instantiation code isn't re-called. It might be worth looking at a model where the client creation code was moved into a private method which is called before each public method and is a noop if it is already active. This way, all of the methods always work…

I've fixed it for my case, but I'm happy to help think through a better API (and maybe send a PR) if desired.

Thanks for this gem! It certainly made an odd case I ran into much easier.