Утечка дескриптора файла (возможно) в библиотеке C создает проблемы с NFS (+ python, но это случайно) - PullRequest
2 голосов
/ 18 мая 2011

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

У меня есть скрипт python (основной), который вызывает модуль 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. У вас есть идея, что мы можем попытаться это исправить?

Ответы [ 2 ]

1 голос
/ 19 мая 2011

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

1 голос
/ 18 мая 2011

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

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

...