Могу ли я активировать аварийные сигналы fcntl и Perl?

Question

Я нахожусь в linux, nfs, с несколькими задействованными машинами.

Я пытаюсь использовать fcntl для реализации блокировки файлов. Я использовал стаю, пока не обнаружил, что она работает только между процессами на одной машине.

Теперь, когда я вызываю fcntl с помощью F_SETLKW, аварийные сигналы perl (для добавления тайм-аута) не работают, как раньше. Обычно это нормально, но ctrl-c тоже не работает.

Я считаю, что Fcntl проверяет только сигналы каждые 30 секунд. Тревога возвращается в конце концов. Ctrl-c пойман, ... в конце концов.

Есть ли что-нибудь, что я могу сделать, чтобы настроить частоту, с которой fcntl проверяет эти сигналы?

Answer 1

Я определенно не эксперт по этому вопросу, но я знаю, что fcntl, как вы уже сказали, не будет работать в вашем случае. Контрольные блокировки fcntl имеют смысл только в одной машине.

Так что забудьте меня, если это не по теме. Я использовал File::NFSLock для решения проблемы кеш-бури/проблемы с собакой/штампованием. Было несколько серверов приложений, которые читали и записывали файлы кеша на томе NFS (не очень хорошая идея, но это было то, с чего мы начали).

Я подклассифицировал/завернул файл :: NFSLock, чтобы изменить его поведение. В частности, мне нужно было:

• стойких замки, которые не уходят, когда объект File :: NFSLock выходит из области видимости. Используя обычный File :: NFSLock, ваша блокировка исчезнет, ​​когда объект выходит из области видимости. Это было не то, что мне нужно.
• , что фактические файлы блокировки также содержат имя машины, которая приобрела замок. Идентификатора процесса явно недостаточно, чтобы решить, завершен ли процесс, поэтому я могу безопасно украсть файл блокировки. Поэтому я изменил код для записи lockfiles как machine:pid, а не только pid.

Это работало чудесно в течение нескольких лет.

До тех пор, пока объем запросов не увеличился в 10 раз. То есть, в прошлом месяце я начал испытывать первые проблемы, когда на самом деле загруженный файл кэша записывался двумя бэкендами на то же время, оставляя мертвые блокировки позади. Это произошло для меня, когда мы достигли общего просмотра страниц за 9-10 месяцев в день, чтобы дать вам представление.

Окончательный сломанный кэш-файл выглядел так:

<!-- START OF CACHE FILE BY BACKEND b1 --> 
... cache file contents ... 
<!-- END OF CACHE FILE BY BACKEND b1 --> 
... more cache file contents ... wtf ... 
<!-- END OF CACHE FILE BY BACKEND b2 --> 

Это может произойти только тогда, когда два движки писать в тот же файл, в то же время ... Это еще не ясно, если эта проблема вызвана Файл: : NFSLock + наши моды или некоторые ошибки в приложении.

В заключение, если ваше приложение не очень загружено и продано, перейдите на File :: NFSLock, я думаю, что это ваш лучший выбор. Вы уверены, что хотите использовать NFS?