close doesn't finish smbclient process about sambal HOT 10 CLOSED

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

from sambal.

Thank you.

from sambal.

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.

from sambal.

Thanks for merging #9

from sambal.

@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!

from sambal.

@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?

from sambal.

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…

from sambal.

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

from sambal.

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.

from sambal.

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.

from sambal.