Too many open files issue from libgit2

[WaffleLapkin]

My program, that uses git2 crushes ~every week because of leaking descriptors. This is probably caused by libgit2/libgit2#2758, which was fixed a while ago.

Is it possible to fix the rust binding too? (If I understand right, this requires an update of the libgit2 dependency)

[alexcrichton]

Updates of the libgit2 module should be fine! Feel free to send a PR which updates it to the latest master branch of libgit2.

[ehuss]

@WaffleLapkin libgit2-sys-0.12.13+1.0.1 already included libgit2/libgit2#5396. Which version are you using? Also, libgit2 was just updated in #627 (released as 0.12.14+1.1.0), you can maybe try that to see if it helps.

[WaffleLapkin]

@ehuss thanks for the callout!

I was using git2 v0.13.6 with libgit2-sys v0.12.7+1.0.0. I'll try to update it and see if it will help.

[WaffleLapkin]

Hm, it seems like even with git2 v0.13.12/libgit2-sys v0.12.14+1.1.0 descriptors are still leaking (most of the descriptors are .git/objects/pack/pack-<...>.{idx,pack}). I've updated everything yesterday and today there are already ~3028 open file descriptors (output of lsof -p <PID> | wc -l)

Upd: I've rechecked after an hour, there are 3072 descriptors now which means that they are indeed leaking

[lhchavez]

@WaffleLapkin are these mostly .pack files? if so, that's expected, since we mmap(2) those files and keep them around: libgit2/libgit2#5396 (comment)

also, can you try setting the GIT_OPT_SET_MWINDOW_FILE_LIMIT configuration option to see if that addresses the issue? The default is unlimited.

[christian-schilling]

@WaffleLapkin Are you keeping an instance of git2::Repository around for a long time?
I used to do that and also observed file handles never getting closed but during the lifetime of git2::Repository this
is ok I think. If you are implementing a long process it is probably a better idea to git2::Repository::open(..) whenever there is any work to do and then discard it when done.
If you are already doing it this way and there are still leaking descriptors that would be a bigger problem.

[WaffleLapkin]

@WaffleLapkin are these mostly .pack files? if so, that's expected, since we mmap(2) those files and keep them around: libgit2/libgit2#5396 (comment)

Ah, that's interesting. When I used lsof -p PID | grep -v '\bmem\b' | grep \.pack\$ | wc -l and ls /proc/PID/fd -1 | wc -l they reported 833 (843). It's much better than I thought before :D

also, can you try setting the GIT_OPT_SET_MWINDOW_FILE_LIMIT configuration option to see if that addresses the issue? The default is unlimited.

Oh, after reading the libgit2/libgit2#5396 description, I've thought that the default is 128. After setting the GIT_OPT_SET_MWINDOW_FILE_LIMIT option the grow stopped exactly at the limit.

git2 rust crate though doesn't seem to provide this setting, so I ended up using libgit2-sys & unsafe:

unsafe {
    dbg!(libgit2_sys::git_libgit2_opts(
        libgit2_sys::GIT_OPT_SET_MWINDOW_FILE_LIMIT as _,
        128
    ))
};

It's awful, but it works. I wonder why this functionality isn't provided by the git2 crate?

Anyway, thanks @lhchavez!

[WaffleLapkin]

@initcrash I'm working with git a lot, so while I thought about this solution, I didn't want to use it.

[lhchavez]

Oh, after reading the libgit2/libgit2#5396 description, I've thought that the default is 128. After setting the GIT_OPT_SET_MWINDOW_FILE_LIMIT option the grow stopped exactly at the limit.

oh rats. that was my original intention, but at some point during the review process that default was pedalled back and i completely forgot to update the message D:

but glad that things worked out one way or the other!