Как иметь дело с задержкой NFS в сценариях оболочки

Я бы сказал , что способ проверить строку в текстовом файле - это grep.

В чем конкретно ваша проблема?

Также вы могли бы настройте параметры монтирования NFS, чтобы избавиться от проблемы с корнем. Также может помочь синхронизация. См. Документацию по NFS.

Если вы хотите использовать waitLoop в «если», вы можете изменить «выход» на «возврат», чтобы остальная часть скрипта могла справиться с ошибочной ситуацией. (нет даже сообщения для пользователя о том, что не удалось, прежде чем сценарий умрет в противном случае.)

Другая проблема заключается в использовании «$ test» для удержания команды, что означает, что вы не получаете расширения оболочки при фактическом выполнении, а только при оценке. Поэтому, если вы скажете test = "grep \" foo \ "\" bar baz \ "", вместо того, чтобы искать трехбуквенную строку foo в файле с семисимвольной строкой имени bar baz, он будет искать строку из пяти символов "foo" в файле из девяти символов "bar baz".

Таким образом, вы можете либо решить, что вам не нужна магия оболочки, и установить test = 'grep -sq ^ sometext $ somefilename', или вы можете заставить оболочку обрабатывать цитирование явно с помощью чего-то вроде:

if /bin/sh -c "$test"
then
   ...

Попробуйте использовать время модификации файла, чтобы определить, когда он записан, не открывая его. Что-то вроде

old_mtime=`stat --format="%Z" file`
# Write to file.
new_mtime=$old_mtime
while [[ "$old_mtime" -eq "$new_mtime" ]]; do 
  sleep 2;
  new_mtime=`stat --format="%Z" file`
done

Однако это не сработает, если несколько процессов попытаются получить доступ к файлу одновременно.

У меня была точно такая же проблема. Я использовал аналогичный подход к ожиданию тайм-аута, которое вы включаете в свой OP; однако я также включил проверку размера файла. Я сбрасываю таймер тайм-аута, если файл увеличился в размере с момента последней проверки. Файлы, которые я пишу, могут иметь размер несколько гигабайт, поэтому их запись через NFS может занять некоторое время.

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

У нас похожая проблема, но по другим причинам. Мы читаем файл, который отправляется на сервер SFTP. Машина, на которой запущен сценарий, не является SFTP-сервером.

Я настроил его в cron (хотя цикл со спящим режимом тоже подойдет) для выполнения cksum файла. Когда старый cksum совпадает с текущим cksum (файл не менялся в течение определенного времени), мы знаем, что запись завершена, и передаем файл.

Для большей безопасности мы никогда не перезаписываем локальный файл раньше делать резервную копию и передавать только тогда, когда в удаленном файле есть две совпадающие cksums подряд, и эта cksum не соответствует локальному файлу.

Если вам нужны примеры кода, я уверен, что смогу их откопать.

Оболочка разбивала ваш предикат на слова. Возьмите все это с помощью $ @ , как в коде ниже:

#! /bin/bash

waitFor()
{
  local tries=$1
  shift
  local predicate="$@"

  while [ $tries -ge 1 ]; do
    (( tries-- ))

    if $predicate >/dev/null 2>&1; then
      return
    else
      [ $tries -gt 0 ] && sleep 1
    fi
  done

  exit 1
}

pred='[ -e /etc/passwd ]'
waitFor 5 $pred
echo "$pred satisfied"

rm -f /tmp/baz
(sleep 2; echo blahblah >>/tmp/baz) &
(sleep 4; echo hasfoo   >>/tmp/baz) &

pred='grep ^hasfoo /tmp/baz'
waitFor 5 $pred
echo "$pred satisfied"

Вывод:

$ ./waitngo 
[ -e /etc/passwd ] satisfied
grep ^hasfoo /tmp/baz satisfied

Жаль, что машинописный текст не так интересен, как просмотр его в реальном времени.

Хорошо. ...это немного странно...

Если у вас есть контроль над файлом: вы можете создать здесь "именованную трубу". Так что (в зависимости от того, как работает программа для записи) вы можете контролировать файл синхронно.

В простейшем случае:

Создайте именованную трубку:

mkfifo file.txt

Установите приемник синхронизации:

while :
do
    process.sh < file.txt
end

Создайте тестового отправителя:

echo "Hello There" > file.txt

В 'process.sh' - это то, куда движется ваша логика: она будет блокироваться до тех пор, пока отправитель не запишет свой вывод. Теоретически программе-писателю не понадобится модификация....

WARNING: если по какой-то причине приемник не работает, вы можете заблокировать отправителя!

Не уверен, что это подходит под ваши требования, но, возможно, стоит посмотреть.

Или, чтобы избежать синхронизации, попробуйте 'lsof' ?

http://en.wikipedia.org/wiki/Lsof

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