У нас есть несколько демонов, работающих на нескольких хостах.
Образы исполняемых файлов демона - это очень большие двоичные файлы, размещенные на NFS.
Когда двоичные файлы обновляются на сервере NFS, ранее запущенные демоны иногда падают с ошибкой шины. Я предполагаю, что происходит то, что сервер NFS заменяет двоичные файлы способом, невидимым для слоя VFS на клиентах NFS, поэтому они в конечном итоге загружают страницы из обновленного двоичного файла, что, конечно же, приводит к безумию.
Мы попытались переместить новые двоичные файлы на место вместо cp, но, похоже, это не помогло.
Я рассматриваю возможность просто использовать mlock () двоичный файл в сценарии запуска демона, но, безусловно, есть волшебные параметры или семантика NFS, которыми мы должны злоупотреблять. Есть ли лучший способ исправить это?
Лучшее решение, которое мы нашли, - всегда устанавливать двоичный файл со строкой версии в конце его имени и поддерживать символическую ссылку, всегда указывающую на последнюю версию.
/mnt/foo/bar -> bar-20111201000000
/mnt/foo/bar-20111201000000
/mnt/foo/bar-20111115000000
При установке новой версии вы атомарно перемещаете новую символическую ссылку поверх старой.
Когда вы запускаете двоичный файл из NFS, ваш процесс сопоставляет имя двоичного файла с версией, которое не будет мешать новым установкам. У него также есть эта изящная бонусная функция, когда вы можете запустить ps и сразу увидеть, какая версия двоичного файла запущена.
Это обычная проблема с NFS. Когда вы удаляете файл, существующее соединение NFS считает, что таблица статистики верна, переходит на перезагрузку и получает ошибку шины.
Что вы хотите сделать, так это переместить существующий двоичный файл, поместить новый двоичный файл на место, после того, как каждая из машин начнет использовать новый двоичный файл, удалить старый. Apache делает это, когда пытается преобразовать файлы, обслуживаемые mmap из NFS, которые также изменяются.