Особые соображения при выполнении файлового ввода-вывода на общем ресурсе NFS через демон на основе Python?

У меня есть демон на основе Python, который предоставляет REST-подобный интерфейс через HTTP для некоторых команд. линейные инструменты . Общий характер этого инструмента заключается в том, чтобы принять запрос, выполнить некоторые действия в командной строке, сохранить структуру данных на диск и вернуть некоторые данные вызывающей стороне. При запуске демона запускается вторичный поток, который периодически просматривает эти маринованные данные на диске и выполняет некоторую очистку в зависимости от того, что находится в данных.

Это отлично работает, если диск, на котором находятся маринованные данные, оказывается локальным диском на Машина Linux. Если вы переключитесь на диск, смонтированный по NFS, демон начинает жизнь нормально, но со временем смонтированный по NFS общий ресурс «исчезает», и демон больше не может определить, где он находится на диске с помощью таких вызовов, как os.getcwd () . Вы начнете видеть, как он регистрирует такие ошибки, как:

2011-07-13 09:19:36,238 INFO Retrieved submit directory '/tech/condor_logs/submit'
2011-07-13 09:19:36,239 DEBUG CondorAgent.post_submit.do_submit(): handler.path: /condor/submit?queue=Q2%40scheduler
2011-07-13 09:19:36,239 DEBUG CondorAgent.post_submit.do_submit(): submitting from temporary submission directory '/tech/condor_logs/submit/tmpoF8YXk'
2011-07-13 09:19:36,240 ERROR Caught un-handled exception: [Errno 2] No such file or directory
2011-07-13 09:19:36,241 INFO submitter - - [13/Jul/2011 09:19:36] "POST /condor/submit?queue=Q2%40scheduler HTTP/1.1" 500 -

Необработанное исключение разрешает демон больше не видеть диск. Любые попытки определить текущий рабочий каталог демона с помощью os.getcwd () на этом этапе потерпят неудачу. Даже попытка перейти в корень монтирования NFS / tech не удастся. Все это время методы logger.logging. * успешно записывают сообщения журнала и отладочные сообщения в файл журнала, расположенный на общем ресурсе, подключенном к NFS, по адресу / tech / condor_logs / logs / CondorAgentLog .

Диск определенно все еще доступен. Существуют и другие демоны, основанные на C ++, которые читают и записывают с гораздо более высокой частотой на этом ресурсе в то время, когда демон на основе python.

Я зашел в тупик, пытаясь отладить эту проблему. Поскольку он работает на локальном диске, общая структура кода должна быть хорошей, верно? Есть что-то несовместимое с подключенными к NFS общими ресурсами и моим кодом, но я не могу сказать, что это может быть.

Есть ли особые соображения, которые нужно учитывать при работе с давно работающим демоном Python, который будет часто читать и писать в общий файловый ресурс, смонтированный по NFS?

Если кто-то хочет увидеть код, часть, которая обрабатывает HTTP-запрос и записывает обработанный объект на диск, находится в github здесь . А часть, которую подпоток использует для периодической очистки содержимого с диска путем чтения замаринованных объектов, здесь .