Я использую tail -f для мониторинга файла журнала, в который ведется активная запись. Когда в файл журнала записывается определенная строка, я хочу выйти из режима мониторинга и продолжить работу с остальным сценарием.
В настоящее время я использую:
tail -f logfile.log | grep -m 1 "Server Started" Когда строка найдена, grep завершает работу, как и ожидалось, но мне нужно найти способ заставить команду tail выйти так, чтобы скрипт мог продолжаться.
Принятый ответ не работает для меня, плюс он сбивает с толку и меняет файл журнала.
Я использую что-то вроде этого:
tail -f logfile.log | while read LOGLINE do [[ "$" == *"Server Started"* ]] && pkill -P $$ tail done Если строка журнала соответствует шаблону, уничтожьте tailзапущенный этим сценарием.
Примечание: если вы также хотите просмотреть вывод на экране, либо | tee /dev/ttyпередайте эхо-строку перед тестированием в цикле while.
Here is a simple one-liner. It doesn't need bash-specific or non-POSIX tricks, or even a named pipe. All you really need is to decouple the termination of tail from grep. That way, once grep ends, the script can continue even if tail hasn't ended yet. So this simple method will get you there:
( tail -f -n0 logfile.log & ) | grep -q "Server Started" grep will block until it has found the string, whereupon it will exit. By making tail run from it's own sub-shell, we can place it in the background so it runs independently. Meanwhile, the main shell is free to continue execution of the script as soon as grep exits. tail will linger in its sub-shell until the next line has been written to the logfile, and then exit (possibly even after the main script has terminated). The main point is that the pipeline no longer waits for tail to terminate, so the pipeline exits as soon as grep exits.
Some minor tweaks:
tail makes it start reading from the current last line of logfile, in case the string exists earlier in the logfile.tail -F rather than -f. It is not POSIX, but it allows tail to work even if the log is rotated while waiting.grep quit after the first occurrence, but without printing out the trigger line. Also it is POSIX, which -m1 isn't.Есть несколько способов добраться tailдо выхода:
tailнаписать еще одну строкуВы можете принудительно tailнаписать еще одну строку вывода сразу после того, grepкак нашли совпадение и вышли. Это приведет tailк тому SIGPIPE, что он получит выход. Один из способов сделать это - изменить файл, отслеживаемый tailпосле grepвыхода.
Вот пример кода:
tail -f logfile.log | grep -m 1 "Server Started" | { cat; echo >>logfile.log; } В этом примере catне будет выходить до grepтех пор, пока не закроет свой стандартный вывод, поэтому tailвряд ли сможет писать в канал до того, как сможет grepзакрыть свой стандартный вывод. catиспользуется для распространения стандартного вывода grepнеизмененного.
Этот подход относительно прост, но есть несколько недостатков:
grepзакрыть stdout перед закрытием stdin, всегда будет условие гонки: grepзакрытие stdout, запуск catдля выхода, запуск echo, запуск tailдля вывода строки. Если эта строка отправлена до того, grepкак grepу нее была возможность закрыть стандартный ввод, tailона не будет получена, пока не будет SIGPIPEзаписана другая строка.tail- он не будет работать с другими программами.bash«ы PIPESTATUSмассив). В этом случае это не имеет большого значения, потому grepчто всегда будет возвращать 0, но в целом средняя стадия может быть заменена другой командой, код возврата которой вам небезразличен (например, что-то, что возвращает 0 при обнаружении «запуска сервера», 1 когда "сервер не запустился" обнаружено).Следующие подходы позволяют избежать этих ограничений.
Вы можете использовать FIFO, чтобы полностью избежать конвейера, позволяя продолжить выполнение после grepвозврата. Например:
fifo=/tmp/tmpfifo.$$ mkfifo "$" || exit 1 tail -f logfile.log >$ & tailpid=$! # optional grep -m 1 "Server Started" "$" kill "$" # optional rm "$" Строки, отмеченные комментарием, # optionalмогут быть удалены, и программа все равно будет работать; tailбудет просто задерживаться, пока не прочитает другую строку ввода или не будет уничтожен каким-либо другим процессом.
Преимущества этого подхода:
tailgrep(или любую другую альтернативную команду, которую вы используете)Недостатком этого подхода является сложность, особенно управление FIFO: вам нужно будет безопасно сгенерировать временное имя файла, и вам нужно будет убедиться, что временный FIFO удален, даже если пользователь нажимает Ctrl-C в середине сценарий. Это можно сделать с помощью ловушки.
tailВы можете получить выход из tailэтапа конвейера, отправив ему сигнал типа SIGTERM. Задача состоит в том, чтобы точно знать две вещи в одном и том же месте в коде: tailPID и был ли grepвыход.
При использовании конвейерного типа tail -f ... | grep ...легко изменить первый этап конвейера, чтобы сохранить tailPID в переменной с помощью фонового изображения tailи чтения $!. Также легко изменить второй этап конвейера для запуска killпри grepвыходе. Проблема заключается в том, что два этапа конвейера работают в отдельных «средах выполнения» (в терминологии стандарта POSIX), поэтому второй этап конвейера не может читать переменные, установленные первым этапом конвейера. Без использования переменных оболочки либо второй этап должен каким-то образом определять tailPID, чтобы он мог завершиться tailпри grepвозврате, либо первый этап должен быть каким-то образом уведомлен при grepвозврате.
Второй этап можно использовать pgrepдля получения tailPID, но это будет ненадежно (вы могли бы соответствовать неправильному процессу) и непереносимо ( pgrepне указано в стандарте POSIX).
Первый этап может отправить PID на второй этап через канал, echoиспользуя PID, но эта строка будет смешана с tailвыходными данными. Демультиплексирование двух может потребовать сложной схемы экранирования, в зависимости от вывода tail.
Вы можете использовать FIFO, чтобы второй этап конвейера уведомлял первый этап конвейера при grepвыходе. Тогда первый этап может убить tail. Вот пример кода:
fifo=/tmp/notifyfifo.$$ mkfifo "$" || exit 1 { # run tail in the background so that the shell can # kill tail when notified that grep has exited tail -f logfile.log & # remember tail's PID tailpid=$! # wait for notification that grep has exited read foo <$ # grep has exited, time to go kill "$" } | { grep -m 1 "Server Started" # notify the first pipeline stage that grep is done echo >$ } # clean up rm "$" Этот подход имеет все плюсы и минусы предыдущего подхода, за исключением того, что он более сложный.
POSIX позволяет полностью буферизовать потоки stdin и stdout, что означает, что tailвыходные данные могут не обрабатываться grepсколь угодно долго. В системах GNU не должно быть никаких проблем: GNU grepиспользует read(), что исключает любую буферизацию, а GNU tail -fделает регулярные вызовы fflush()при записи в stdout. В системах без GNU может потребоваться сделать что-то особенное, чтобы отключить или регулярно очищать буферы.
Если вы используете Bash (по крайней мере, но кажется, что он не определен POSIX, поэтому он может отсутствовать в некоторых оболочках), вы можете использовать синтаксис
grep -m 1 "Server Started" <(tail -f logfile.log) Он работает почти так же, как уже упоминавшиеся решения FIFO, но гораздо проще в написании.
Позвольте мне расширить ответ @ 00promeheus (который является лучшим).
Может быть, вы должны использовать тайм-аут, а не ждать бесконечно.
Приведенная ниже функция bash будет блокироваться до тех пор, пока не появится заданное условие поиска или не истечет заданное время ожидания.
Статус выхода будет 0, если строка найдена в течение времени ожидания.
wait_str() { local file="$1"; shift local search_term="$1"; shift local wait_time="$"; shift # 5 minutes as default timeout (timeout $wait_time tail -F -n0 "$file" &) | grep -q "$search_term" && return 0 echo "Timeout of $wait_time reached. Unable to find '$search_term' in '$file'" return 1 } Возможно, файл журнала еще не существует только после запуска вашего сервера. В этом случае вам следует подождать, пока он появится, прежде чем искать строку:
wait_server() { echo "Waiting for server..." local server_log="$1"; shift local wait_time="$1"; shift wait_file "$server_log" 10 || { echo "Server log file missing: '$server_log'"; return 1; } wait_str "$server_log" "Server Started" "$wait_time" } wait_file() { local file="$1"; shift local wait_seconds="$"; shift # 10 seconds as default timeout until test $((wait_seconds--)) -eq 0 -o -f "$file" ; do sleep 1; done ((++wait_seconds)) } Вот как вы можете использовать это:
wait_server "/var/log/server.log" 5m && \ echo -e "\n-------------------------- Server READY --------------------------\n" So after doing some testing, I found a quick 1-line way to make this work. It appears tail -f will quit when grep quits, but there's a catch. It appears to only be triggered if the file is opened and closed. I've accomplished this by appending the empty string to the file when grep finds the match.
tail -f logfile |grep -m 1 "Server Started" | xargs echo "" >> logfile \; I'm not sure why the open/close of the file triggers tail to realize that the pipe is closed, so I wouldn't rely on this behavior. but it seems to work for now.
Reason it closes, look at the -F flag, versus the -f flag.
В настоящее время, как указано, все tail -fрешения, представленные здесь, рискуют подхватить ранее зарегистрированную строку «Server Started» (что может или не может быть проблемой в вашем конкретном случае, в зависимости от количества зарегистрированных строк и ротации файла журнала / усечение).
Вместо того, чтобы слишком усложнять вещи, просто используйте умнее tail, как показал bmike с фрагментом perl. Самое простое решение - это retailвстроенная поддержка регулярных выражений с шаблонами условий запуска и остановки :
retail -f -u "Server Started" server.log > /dev/null Это будет следовать за файлом, как обычно, tail -fпока не появится первый новый экземпляр этой строки, а затем завершится. ( -uОпция не срабатывает на существующие строки в последних 10 строках файла в обычном режиме «Follow».)
Если вы используете GNU tail(из coreutils ), следующий простейший вариант - использовать --pidFIFO (именованный канал):
mkfifo $ grep -q -m 1 "Server Started" $ & tail -n 0 -f server.log --pid $! >> $ rm $ FIFO используется, потому что процессы должны запускаться отдельно, чтобы получить и передать PID. ФИФО по- прежнему страдает от тех же проблем торчать для своевременной записи, чтобы вызвать tailполучить в SIGPIPE, используйте --pidопцию, так что tailвыходит, когда он замечает, что grepокончилось (обычно используются для контроля писателя процесса, а не на читателе, но tailБезразлично» Т действительно волнует). Опция -n 0используется для tailтого, чтобы старые строки не вызывали совпадения.
Наконец, вы можете использовать хвост с сохранением состояния, при этом будет сохраняться текущее смещение файла, поэтому последующие вызовы будут отображать только новые строки (он также обрабатывает поворот файла). В этом примере используется старый FWTK retail*:
retail "$" > /dev/null # skip over current content while true; do [ "$" -nt ".$.off" ] && retail "$" | grep -q "Server Started" && break sleep 2 done * Примечание, то же имя, программа отличается от предыдущей опции.
Вместо того, чтобы зацикливаться на процессоре, сравните временную метку файла с состоянием file ( .$.off) и sleep. Используйте " -T", чтобы указать местоположение файла состояния, если требуется, вышеупомянутый предполагает текущий каталог. Не стесняйтесь пропустить это условие, или в Linux вы можете использовать более эффективное inotifywaitвместо этого:
retail "$" > /dev/null while true; do inotifywait -qq "$" && retail "$" | grep -q "Server Started" && break done Это будет немного сложнее, так как вам придется войти в управление процессом и сигнализацию. Больше kludgey было бы решением с двумя сценариями, использующим отслеживание PID. Лучше бы использовать именованные каналы, как это.
Какой сценарий оболочки вы используете?
Для быстрого и грязного, одного сценария решения - я бы сделал Perl-скрипт, используя File: Tail
use File::Tail; $file=File::Tail->new(name=>$name, maxinterval=>300, adjustafter=>7); while (defined($line=$file->read)) { last if $line =~ /Server started/; } Поэтому вместо того, чтобы печатать внутри цикла while, вы можете отфильтровать совпадения строк и выйти из цикла while, чтобы ваш сценарий продолжался.
Любой из них должен включать в себя лишь небольшое обучение для реализации контроля потока наблюдения, который вы ищете.
дождитесь появления файла
while [ ! -f /path/to/the.file ] do sleep 2; done дождитесь появления строки в файле
while ! grep "the line you're searching for" /path/to/the.file do sleep 10; done I can't imagine a cleaner solution than this one:
#!/usr/bin/env bash # file : untail.sh # usage: untail.sh logfile.log "Server Started" (echo $BASHPID; tail -f $1) | while read LINE ; do if [ -z $TPID ]; then TPID=$LINE # the first line is used to store the previous subshell PID else echo "$LINE"; [[ "$LINE" == *"${*:2}"* ]] && kill -3 $TPID && break fi done ok, maybe the name can be subject to improvements...
Advantages: