Ошибка дескриптора файла (может быть) в библиотеке C создает проблемы с NFS (+ python, но это случайно)

Question

вот довольно крутая проблема.

У меня есть сценарий python (main), который вызывает модуль python (foo.py), который, в свою очередь, вызывает другой модуль python (barwrapper.py), использует LoadLibrary для динамического открытия и доступа к библиотеке libbar.so.

libbar и весь остаток цепи открыты и создают файлы для выполнения своей задачи. Проблема возникает, когда мы выписываем rmtree в главном скрипте python, чтобы избавиться от временного каталога, созданного импортированными модулями. rmtree вызывается в конце скрипта непосредственно перед выходом. Вызов завершился неудачно, потому что каталог содержит .nfs-whatever скрытые файлы, которые, я думаю, являются удаленными файлами. Эти файлы, по-видимому, остаются открытыми в коде, заставляя nfs перемещать их в эти файлы .nfs-whatever до тех пор, пока не будет выпущен дескриптор файла. Такая ситуация не возникает в других файловых системах, потому что файлы, связанные с дескрипторами, эффективно удаляются, но остаются доступными ядром до тех пор, пока дескриптор не будет закрыт.

Мы сильно подозреваем, что библиотека .so пропускает дескрипторы файлов, и эти незаблокированные файлы разрушают партию rmtree во время очистки. Я думал о разгрузке файла .so в barwrapper, но, видимо, этого не сделать, и я не уверен, что dynloader фактически удалит lib из пространства процесса и закроет дескрипторы, или если он просто пометит его разгрузкой и все, ожидая замены другими вещами, но с просачивающимися дескрипторами.

Я не могу думать о других обходных решениях проблемы (кроме устранения утечек, чего мы не хотели бы делать, поскольку это сторонняя библиотека). Ясно, что это происходит только на nfs. Есть ли у вас какие-либо идеи, мы можем попытаться исправить это?

Answer 1

Хорошее решение заключается в устранении утечки ручек, но если вы не уверены в утечке, возможно, звонок strace поможет вам локализовать утечку и отправить ошибку сторонним разработчикам сторонней библиотеки (или лучше, если это библиотека с открытым исходным кодом, попробуйте отправить патч;)).

С другой стороны, возможно, что umount/mount на разделе nfs может помочь принудительно закрыть ручки.

Answer 2

Ядро отслеживает файловые дескрипторы, поэтому даже если вы получили python для выгрузки .so и освобождения памяти, он не знал бы закрыть пропущенные файловые дескрипторы. Единственное, что приходит на ум - импортировать .so после форкирования, и только очистка после выталкивания дочернего процесса (и файл неявно закрывается при выходе ядром).