Я использую tail -f для мониторинга файла журнала, в который ведется активная запись. Когда в файл журнала записывается определенная строка, я хочу выйти из режима мониторинга и продолжить работу с остальным сценарием.

В настоящее время я использую:

tail -f logfile.log | grep -m 1 "Server Started"

Когда строка найдена, grep завершает работу, как и ожидалось, но мне нужно найти способ заставить команду tail выйти так, чтобы скрипт мог продолжаться.

Простой POSIX с одним вкладышем

Вот простая однострочная. Для этого не нужны специфичные для bash или не POSIX трюки, или даже именованный канал. Все, что вам действительно нужно, это отделить окончание tailот grep. Таким образом, после grepзавершения сценарий может продолжаться, даже если он tailеще не завершен. Итак, этот простой метод доставит вас туда:

( tail -f -n0 logfile.log & ) | grep -q "Server Started"

grepбудет блокировать, пока не найдет строку, после чего он выйдет. Сделав tailзапуск из его собственной вложенной оболочки, мы можем поместить его в фоновом режиме, чтобы он работал независимо. Между тем основная оболочка может продолжить выполнение скрипта сразу после grepвыхода. tailбудет задерживаться в своей вложенной оболочке до тех пор, пока в лог-файл не будет записана следующая строка, а затем завершится (возможно, даже после завершения основного сценария). Суть в том, что конвейер больше не ожидает tailзавершения, поэтому конвейер завершается сразу после grepвыхода.

Некоторые незначительные изменения:

• Опция -n0 tailпозволяет начинать чтение с текущей последней строки файла журнала, если строка существует ранее в файле журнала.
• Вы можете tailуказать -F, а не -f. Это не POSIX, но он позволяет tailработать, даже если журнал вращается во время ожидания.
• Опция -q вместо -m1 делает grepвыход после первого появления, но без распечатки строки триггера. Также это POSIX, а не -m1.

Принятый ответ не работает для меня, плюс он сбивает с толку и меняет файл журнала.

Я использую что-то вроде этого:

tail -f logfile.log | while read LOGLINE
do
   [[ "${LOGLINE}" == *"Server Started"* ]] && pkill -P $$ tail
done

Если строка журнала соответствует шаблону, уничтожьте tailзапущенный этим сценарием.

Примечание: если вы хотите также просмотреть вывод на экране, либо | tee /dev/ttyпередайте эхо-строку , либо протестируйте в цикле while.

Если вы используете Bash (по крайней мере, но кажется, что он не определен POSIX, поэтому он может отсутствовать в некоторых оболочках), вы можете использовать синтаксис

grep -m 1 "Server Started" <(tail -f logfile.log)

Он работает почти так же, как уже упоминавшиеся решения FIFO, но гораздо проще в написании.

Есть несколько способов добраться 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- он не будет работать с другими программами.
• Этап третий трубопровод делает его трудно получить доступ к коду возврата второго этапа трубопровода (если вы не используете расширение POSIX , таких как bash«s PIPESTATUSмассив). Это не имеет большого значения в этом случае, потому grepчто всегда будет возвращать 0, но в целом средняя стадия может быть заменена другой командой, код возврата которой вам небезразличен (например, что-то, что возвращает 0, когда обнаружен «сервер запущен», 1 когда "сервер не запустился" обнаружено).

Следующие подходы позволяют избежать этих ограничений.

Лучший подход: избегайте трубопроводов

Вы можете использовать FIFO, чтобы полностью избежать конвейера, позволяя продолжить выполнение после grepвозврата. Например:

fifo=/tmp/tmpfifo.$$
mkfifo "${fifo}" || exit 1
tail -f logfile.log >${fifo} &
tailpid=$! # optional
grep -m 1 "Server Started" "${fifo}"
kill "${tailpid}" # optional
rm "${fifo}"

Строки, отмеченные комментарием, # optionalмогут быть удалены, и программа все равно будет работать; tailбудет просто задерживаться, пока не прочитает другую строку ввода или не будет уничтожен каким-либо другим процессом.

Преимущества этого подхода:

• вам не нужно изменять файл журнала
• подход работает для других утилит, кроме tail
• не страдает от состояния гонки
• вы можете легко получить возвращаемое значение grep(или любую другую альтернативную команду, которую вы используете)

Недостатком этого подхода является сложность, особенно управление FIFO: вам нужно будет безопасно сгенерировать временное имя файла, и вам нужно будет убедиться, что временный FIFO удален, даже если пользователь нажимает Ctrl-C в середине сценарий. Это можно сделать с помощью ловушки.

Альтернативный подход: отправить сообщение в Kill 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 "${fifo}" || 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 <${fifo}
    # grep has exited, time to go
    kill "${tailpid}"
} | {
    grep -m 1 "Server Started"
    # notify the first pipeline stage that grep is done
    echo >${fifo}
}
# clean up
rm "${fifo}"

Этот подход имеет все плюсы и минусы предыдущего подхода, за исключением того, что он более сложный.

Предупреждение о буферизации

POSIX позволяет полностью буферизовать потоки stdin и stdout, что означает, что tailвыходные данные могут не обрабатываться grepсколь угодно долго. В системах GNU не должно быть никаких проблем: GNU grepиспользует read(), что исключает любую буферизацию, а GNU tail -fделает регулярные вызовы fflush()при записи в stdout. В системах без GNU может потребоваться сделать что-то особенное, чтобы отключить или регулярно очищать буферы.

Позвольте мне расширить ответ @ 00promeheus (который является лучшим).

Может быть, вы должны использовать тайм-аут, а не ждать бесконечно.

Приведенная ниже функция bash будет блокироваться до тех пор, пока не появится заданное условие поиска или не истечет заданное время ожидания.

Статус выхода будет 0, если строка найдена в течение времени ожидания.

wait_str() {
  local file="$1"; shift
  local search_term="$1"; shift
  local wait_time="${1:-5m}"; 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="${1:-10}"; 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"

Итак, после некоторого тестирования, я нашел быстрый способ с 1 строкой сделать эту работу. Похоже, tail -f выйдет, когда выйдет grep, но есть одна загвоздка. Кажется, он срабатывает только в том случае, если файл открыт и закрыт. Я сделал это, добавив пустую строку в файл, когда grep найдет совпадение.

tail -f logfile |grep -m 1 "Server Started" | xargs echo "" >> logfile \;

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

Причина, по которой он закрывается, посмотрите на флаг -F, а не на флаг -f.

В настоящее время, как указано, все tail -fрешения, представленные здесь, рискуют подхватить ранее зарегистрированную строку «Сервер запущен» (что может или не может быть проблемой в вашем конкретном случае, в зависимости от количества зарегистрированных строк и ротации файла журнала / усечение).

Вместо того, чтобы чрезмерно усложнять вещи, просто используйте умнее tail, как показал bmike с фрагментом perl. Самое простое решение - это retailвстроенная поддержка регулярных выражений с шаблонами условий запуска и остановки :

retail -f -u "Server Started" server.log > /dev/null

Это будет следовать за файлом, как обычно, tail -fпока не появится первый новый экземпляр этой строки, а затем завершится. ( -uОпция не срабатывает на существующие строки в последних 10 строках файла в обычном режиме «Follow».)

Если вы используете GNU tail(из coreutils ), следующий простейший вариант - использовать --pidFIFO (именованный канал):

mkfifo ${FIFO:=serverlog.fifo.$$}
grep -q -m 1 "Server Started" ${FIFO}  &
tail -n 0 -f server.log  --pid $! >> ${FIFO}
rm ${FIFO}

FIFO используется, потому что процессы должны запускаться отдельно, чтобы получить и передать PID. ФИФО по- прежнему страдает от тех же проблем торчать для своевременной записи в дело tailполучить в SIGPIPE , используйте --pidопцию , так что tailвыходит , когда он замечает , что grepокончилось (обычно используется для контроля писателя процесса , а не читатель , но tailБезразлично» т действительно волнует). Опция -n 0используется для tailтого, чтобы старые строки не вызывали совпадения.

Наконец, вы могли бы использовать хвост с сохранением состояния , это сохранит текущее смещение файла, поэтому последующие вызовы будут показывать только новые строки (это также обрабатывает вращение файла). В этом примере используется старый FWTK retail*:

retail "${LOGFILE:=server.log}" > /dev/null   # skip over current content
while true; do
    [ "${LOGFILE}" -nt ".${LOGFILE}.off" ] && 
       retail "${LOGFILE}" | grep -q "Server Started" && break
    sleep 2
done

_{* Примечание, то же имя, программа отличается от предыдущей опции.}

Вместо того, чтобы использовать цикл с переключением процессора, сравните временную метку файла с состоянием file ( .${LOGFILE}.off) и sleep. Используйте « -T», чтобы указать местоположение файла состояния, если требуется, выше предполагается, что текущий каталог. Не стесняйтесь пропустить это условие, или в Linux вы можете использовать более эффективное inotifywait:

retail "${LOGFILE:=server.log}" > /dev/null
while true; do
    inotifywait -qq "${LOGFILE}" && 
       retail "${LOGFILE}" | 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

https://superuser.com/a/743693/129669

Я не могу представить себе более чистого решения, чем это:

#!/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

хорошо, может быть имя может быть улучшено ...

Преимущества:

• он не использует никаких специальных утилит
• он не записывает на диск
• он грациозно покидает хвост и закрывает трубу
• это довольно коротко и легко понять

Вам не нужен хвост, чтобы сделать это. Я думаю, что команда часов это то, что вы ищете. Команда watch контролирует вывод файла и может быть прервана с помощью опции -g при изменении вывода.

watch -g grep -m 1 "Server Started" logfile.log && Yournextaction

Алекс, я думаю, что это поможет тебе.

tail -f logfile |grep -m 1 "Server Started" | xargs echo "" >> /dev/null ;

эта команда никогда не даст запись в лог-файл, но будет молча grep ...

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

sh -c 'tail -n +0 -f /tmp/foo | { sed "/EOF/ q" && kill $$ ;}'

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

Другие решения здесь имеют несколько проблем:

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

Вот то, что я придумал, используя tomcat в качестве примера (удалите хэши, если вы хотите видеть журнал во время его запуска):

function startTomcat {
    loggingProcessStartCommand="${CATALINA_HOME}/bin/startup.sh"
    loggingProcessOwner="root"
    loggingProcessCommandLinePattern="${JAVA_HOME}"
    logSearchString="org.apache.catalina.startup.Catalina.start Server startup"
    logFile="${CATALINA_BASE}/log/catalina.out"

    lineNumber="$(( $(wc -l "${logFile}" | awk '{print $1}') + 1 ))"
    ${loggingProcessStartCommand}
    while [[ -z "$(sed -n "${lineNumber}p" "${logFile}" | grep "${logSearchString}")" ]]; do
        [[ -z "$(ps -ef | grep "^${loggingProcessOwner} .* ${loggingProcessCommandLinePattern}" | grep -v grep)" ]] && { echo "[ERROR] Tomcat failed to start"; return 1; }
        [[ $(wc -l "${logFile}" | awk '{print $1}') -lt ${lineNumber} ]] && continue
        #sed -n "${lineNumber}p" "${logFile}"
        let lineNumber++
    done
    #sed -n "${lineNumber}p" "${logFile}"
    echo "[INFO] Tomcat has started"
}

Команда tailможет быть фоновой, и ее pid отражается в grepподоболочке. В grepподоболочке обработчик прерываний на EXIT может уничтожить tailкоманду.

( (sleep 1; exec tail -f logfile.log) & echo $! ; wait ) | 
     (trap 'kill "$pid"' EXIT; pid="$(head -1)"; grep -m 1 "Server Started")

Прочитайте их все. tldr: отделить окончание хвоста от grep.

Наиболее удобными являются две формы

( tail -f logfile.log & ) | grep -q "Server Started"

и если у вас есть Баш

grep -m 1 "Server Started" <(tail -f logfile.log)

Но если этот хвост, сидящий на заднем плане, беспокоит вас, есть более хороший способ, чем пятерка или любой другой ответ здесь. Требуется Баш.

coproc grep -m 1 "Server Started"
tail -F /tmp/x --pid $COPROC_PID >&${COPROC[1]}

Или, если это не хвост, который выводит вещи,

coproc command that outputs
grep -m 1 "Sever Started" ${COPROC[0]}
kill $COPROC_PID

Попробуйте использовать inotify (inotifywait)

Вы настраиваете inotifywait для любого изменения файла, затем проверяете файл с помощью grep, если он не найден, просто перезапустите inotifywait, если он найден, выйдите из цикла ...

Вы хотите уйти, как только строка написана, но вы также хотите уйти после тайм-аута:

if (timeout 15s tail -F -n0 "stdout.log" &) | grep -q "The string that says the startup is successful" ; then
    echo "Application started with success."
else
    echo "Startup failed."
    tail stderr.log stdout.log
    exit 1
fi

как насчет этого:

пока правда; делать, если [! -z $ (grep "myRegEx" myLog.log)]; затем сломаться; фи; сделанный