Używam tail -f do monitorowania pliku dziennika, który jest aktywnie zapisywany. Po zapisaniu określonego ciągu do pliku dziennika chcę zakończyć monitorowanie i kontynuować resztę skryptu.

Obecnie używam:

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

Gdy łańcuch zostanie znaleziony, grep kończy działanie zgodnie z oczekiwaniami, ale muszę znaleźć sposób, aby polecenie tail również się zakończyło, aby skrypt mógł kontynuować.

Prosty jednowarstwowy POSIX

Oto prosty jednowarstwowy. Nie potrzebuje sztuczek specyficznych dla basha, nie-POSIX-owych, ani nawet nazwanego potoku. Jedyne, czego naprawdę potrzebujesz, to odłączyć termin tailod grep. W ten sposób po grepzakończeniu skrypt może kontynuować, nawet jeśli tailjeszcze się nie zakończył. Więc ta prosta metoda doprowadzi cię tam:

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

grepbędzie blokować, dopóki nie znajdzie łańcucha, po czym zakończy działanie. Poprzez tailbieg z jego własnym sub-shell, możemy umieścić go w tle tak, że działa niezależnie. Tymczasem główna powłoka może kontynuować wykonywanie skryptu zaraz po grepwyjściu. tailpozostanie w swojej podpowłoce, dopóki następny wiersz nie zostanie zapisany w pliku dziennika, a następnie zakończy działanie (być może nawet po zakończeniu skryptu głównego). Najważniejsze jest to, że rurociąg nie czeka już na tailzakończenie, więc rurociąg kończy się natychmiast po jego zakończeniu grep.

Kilka drobnych poprawek:

• Opcja -n0 tailpowoduje, że zaczyna on czytać od bieżącego ostatniego wiersza pliku dziennika, w przypadku gdy łańcuch istnieje wcześniej w pliku dziennika.
• Możesz podać tail-F zamiast -f. To nie jest POSIX, ale pozwala tailna pracę, nawet jeśli dziennik zostanie obrócony podczas oczekiwania.
• Opcja -q zamiast -m1 powoduje grepwyjście po pierwszym wystąpieniu, ale bez drukowania linii wyzwalającej. Jest to również POSIX, którego nie ma -m1.

Przyjęta odpowiedź nie działa dla mnie, a ponadto jest myląca i zmienia plik dziennika.

Używam czegoś takiego:

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

Jeśli wiersz dziennika pasuje do wzorca, zabij tailstartowany przez ten skrypt.

Uwaga: jeśli chcesz również wyświetlić dane wyjściowe na ekranie, albo | tee /dev/ttywypowiedz linię przed testowaniem w pętli while.

Jeśli używasz Bash (przynajmniej, ale wydaje się, że nie jest zdefiniowany przez POSIX, więc może brakować go w niektórych powłokach), możesz użyć składni

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

Działa prawie tak, jak wspomniane już rozwiązania FIFO, ale jest o wiele prostszy w pisaniu.

Istnieje kilka sposobów tailna wyjście:

Słabe podejście: zmuszenie taildo napisania kolejnej linii

Możesz wymusić tailzapisanie innego wiersza wyników natychmiast po grepznalezieniu dopasowania i wyjściu. Spowoduje to, że taildostaniesz SIGPIPE, powodując jego wyjście. Jednym ze sposobów jest zmodyfikowanie monitorowanego pliku tailpo grepwyjściu.

Oto przykładowy kod:

tail -f logfile.log | grep -m 1 "Server Started" | { cat; echo >>logfile.log; }

W tym przykładzie catnie wyjdzie, dopóki grepnie zamknie standardowego wejścia , więc tailprawdopodobnie nie będzie w stanie pisać do potoku, zanim grepnie będzie miał możliwości zamknięcia standardowego wejścia. catsłuży do propagowania standardowego wyjścia grepniezmodyfikowanego.

To podejście jest stosunkowo proste, ale ma kilka wad:

• Jeśli grepzamyka stdout przed zamknięciem stdin, zawsze wystąpi warunek wyścigu: grepzamyka stdout, wyzwala catwyjście, wyzwala echo, wyzwala tailwyjście linii. Jeśli ta linia została wysłana grepwcześniej grep, miała szansę na zamknięcie standardowego wejścia, tailnie dostanie tego SIGPIPEdopóki nie napisze innej linii.
• Wymaga dostępu do zapisu do pliku dziennika.
• Musisz być w porządku z modyfikowaniem pliku dziennika.
• Możesz uszkodzić plik dziennika, jeśli zdarzy Ci się pisać w tym samym czasie co inny proces (zapisy mogą być przeplatane, co powoduje pojawienie się nowego wiersza w środku komunikatu dziennika).
• To podejście jest specyficzne dla tail- nie będzie działać z innymi programami.
• Trzeci etap rurociąg sprawia, że trudno jest uzyskać dostęp do kodu powrotu drugiego etapu gazociągu (o ile nie używasz rozszerzenia POSIX takich jak bash„s PIPESTATUStablicy). W tym przypadku nie jest to wielka sprawa, ponieważ grepzawsze zwróci 0, ale ogólnie etap środkowy może zostać zastąpiony innym poleceniem, którego kod powrotu jest dla Ciebie ważny (np. Coś, co zwraca 0 po wykryciu „uruchomienia serwera”, 1 gdy zostanie wykryty „serwer nie uruchomił się”).

Kolejne podejścia pozwalają uniknąć tych ograniczeń.

Lepsze podejście: unikaj rurociągów

Możesz użyć FIFO, aby całkowicie uniknąć potoku, umożliwiając kontynuowanie wykonywania po greppowrocie. Na przykład:

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}"

Linie oznaczone komentarzem # optionalmożna usunąć, a program będzie nadal działał; tailpozostanie po prostu, dopóki nie przeczyta innej linii danych wejściowych lub nie zostanie zabity przez inny proces.

Zaletami tego podejścia są:

• nie musisz modyfikować pliku dziennika
• podejście działa również w przypadku innych narzędzi tail
• nie cierpi z powodu wyścigu
• możesz łatwo uzyskać wartość zwracaną grep(lub dowolne alternatywne polecenie, którego używasz)

Wadą tego podejścia jest złożoność, zwłaszcza zarządzanie FIFO: Musisz bezpiecznie wygenerować tymczasową nazwę pliku i musisz upewnić się, że tymczasowa FIFO zostanie usunięta, nawet jeśli użytkownik kliknie Ctrl-C w środku scenariusz. Można to zrobić za pomocą pułapki.

Alternatywne podejście: Wyślij wiadomość do zabicia tail

Możesz dostać tailetap rurociągu do wyjścia, wysyłając mu podobny sygnał SIGTERM. Wyzwaniem jest niezawodna znajomość dwóch rzeczy w tym samym miejscu w kodzie: tailPID i czy grepzakończyło się.

Przy pomocy takiego potoku tail -f ... | grep ...można łatwo zmodyfikować pierwszy etap rurociągu, aby zapisać tailPID w zmiennej poprzez tworzenie tła taili czytanie $!. Łatwo jest również zmodyfikować drugi etap rurociągu, aby działał killpo grepwyjściu. Problem polega na tym, że dwa etapy potoku działają w osobnych „środowiskach wykonawczych” (w terminologii standardu POSIX), więc drugi etap potoku nie może odczytać żadnych zmiennych ustawionych przez pierwszy etap potoku. Bez użycia zmiennych powłoki albo drugi etap musi jakoś ustalić tailPID, aby mógł zabić tailpo greppowrocie, lub pierwszy etap musi zostać w jakiś sposób powiadomiony o greppowrocie.

Drugi etap może posłużyć pgrepdo uzyskania tailPID, ale byłoby to niewiarygodne (możesz dopasować niewłaściwy proces) i nieprzenośne ( pgrepnie jest określone w standardzie POSIX).

Pierwszy stopień może wysłać PID do drugiego stopnia przez rurę, echowprowadzając PID, ale ten ciąg zostanie pomieszany z tailwyjściem. Demultipleksowanie tych dwóch może wymagać złożonego schematu ucieczki, w zależności od wyjścia tail.

Możesz użyć FIFO, aby drugi etap rurociągu powiadomił pierwszy etap rurociągu o grepwyjściu. Wtedy pierwszy etap może zabić tail. Oto przykładowy kod:

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}"

To podejście ma wszystkie zalety i wady poprzedniego podejścia, z tym że jest bardziej skomplikowane.

Ostrzeżenie o buforowaniu

POSIX pozwala na pełne buforowanie strumieni stdin i stdout, co oznacza, że taildane wyjściowe mogą nie być przetwarzane przez grepdowolnie długi czas. W systemach GNU nie powinno być żadnych problemów: GNU grepużywa read(), co pozwala uniknąć buforowania, a GNU tail -fregularnie wywołuje fflush(), pisząc na standardowe wyjście. Systemy inne niż GNU mogą musieć zrobić coś specjalnego, aby wyłączyć lub regularnie opróżniać bufory.

Pozwól mi rozwinąć odpowiedź na @ 00prometheus (która jest najlepsza).

Może powinieneś skorzystać z limitu czasu zamiast czekać w nieskończoność.

Poniższa funkcja bash będzie blokować do momentu pojawienia się wyszukiwanego terminu lub osiągnięcia określonego limitu czasu.

Status wyjścia wyniesie 0, jeśli ciąg zostanie znaleziony w limicie czasu.

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
}

Być może plik dziennika jeszcze nie istnieje tuż po uruchomieniu serwera. W takim przypadku należy zaczekać na jego pojawienie się przed wyszukiwaniem ciągu:

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))
}

Oto jak możesz go użyć:

wait_server "/var/log/server.log" 5m && \
echo -e "\n-------------------------- Server READY --------------------------\n"

Po przeprowadzeniu testów znalazłem szybki 1-liniowy sposób, aby to zadziałało. Wygląda na to, że tail -f przestanie działać, gdy grep zakończy pracę, ale jest pewien haczyk. Wydaje się, że jest uruchamiany tylko wtedy, gdy plik jest otwarty i zamknięty. Osiągnąłem to, dodając pusty ciąg do pliku, gdy grep znajdzie dopasowanie.

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

Nie jestem pewien, dlaczego otwieranie / zamykanie pliku powoduje, że ogon zdaje sobie sprawę, że potok jest zamknięty, więc nie polegałbym na tym zachowaniu. ale wydaje się, że na razie działa.

Powód, dla którego się zamyka, spójrz na flagę -F, w porównaniu z flagą -f.

Obecnie, jak podano, wszystkie przedstawione tail -ftutaj rozwiązania wiążą się z ryzykiem pobrania wcześniej zarejestrowanej linii „Server Started” (co może, ale nie musi stanowić problemu w konkretnym przypadku, w zależności od liczby zalogowanych linii i rotacji pliku dziennika / obcięcie).

Zamiast nadmiernie komplikować rzeczy, po prostu użyj mądrzejszego tail, jak pokazał bmike z snajpatem Perla. Najprostszym rozwiązaniem jest to retail, które ma zintegrowaną obsługę regex ze startu i zatrzymania wzory warunek:

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

Będzie to postępować zgodnie z plikiem jak normalnie, tail -fdopóki nie pojawi się pierwsza nowa instancja tego ciągu, a następnie wyjście. ( -uOpcja nie uruchamia się na istniejących liniach w ostatnich 10 liniach pliku, gdy jest w normalnym trybie „podążania”).

Jeśli używasz GNU tail(z coreutils ), następną najprostszą opcją jest użycie --pidi FIFO (nazwany potok):

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

Stosuje się FIFO, ponieważ procesy muszą być uruchamiane osobno, aby uzyskać i przekazać PID. Kolejka nadal cierpi z tego samego problemu kręci się terminowego zapisu powoduje tailotrzymywać na SIGPIPE , użyj --pidopcji tak, że tailwychodzi, gdy spostrzega, że grepzostał zakończony (konwencjonalnie stosowany do monitorowania pisarz proces zamiast czytnika , ale tailnie robi” to naprawdę obchodzi). Opcja -n 0służy do tailtego, aby stare linie nie wyzwalały dopasowania.

Na koniec możesz użyć stanowego ogona , który zapisze bieżące przesunięcie pliku, więc kolejne wywołania pokażą tylko nowe linie (obsługuje także rotację plików). W tym przykładzie użyto starego 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

_{* Uwaga, ta sama nazwa, inny program niż poprzednia opcja.}

Zamiast mieć pętlę uruchamiania procesora, porównaj znacznik czasu pliku z plikiem stanu ( .${LOGFILE}.off) i uśpienie. Użyj „ -T”, aby określić lokalizację pliku stanu, jeśli jest to wymagane, powyższe zakłada bieżący katalog. Pomiń ten warunek lub w systemie Linux możesz inotifywaitzamiast tego użyć bardziej wydajnego :

retail "${LOGFILE:=server.log}" > /dev/null
while true; do
    inotifywait -qq "${LOGFILE}" && 
       retail "${LOGFILE}" | grep -q "Server Started" && break
done

Będzie to nieco trudne, ponieważ będziesz musiał wejść w kontrolę procesu i sygnalizację. Więcej kludgey byłoby rozwiązaniem dwóch skryptów wykorzystującym śledzenie PID. Lepiej byłoby użyć nazwanych potoków w ten sposób.

Jakiego skryptu powłoki używasz?

Dla szybkiego i brudnego rozwiązania dla jednego skryptu - zrobiłbym skrypt w Perlu za pomocą 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/;
}

Zamiast drukować wewnątrz pętli while, możesz filtrować pod kątem dopasowania łańcucha i zerwać z pętli while, aby skrypt mógł kontynuować.

Każdy z nich powinien wymagać jedynie odrobiny nauki implementacji kontroli przepływu, której szukasz.

poczekaj na pojawienie się pliku

while [ ! -f /path/to/the.file ] 
do sleep 2; done

poczekaj, aż łańcuch pojawi się w pliku

while ! grep "the line you're searching for" /path/to/the.file  
do sleep 10; done

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

Nie mogę sobie wyobrazić czystszego rozwiązania niż to:

#!/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, może nazwa może ulec poprawie ...

Zalety:

• nie używa żadnych specjalnych narzędzi
• nie zapisuje na dysk
• z wdziękiem opuszcza ogon i zamyka fajkę
• jest dość krótki i łatwy do zrozumienia

Aby to zrobić, nie potrzebujesz ogona. Myślę, że zegarek komenda jest to, czego szukasz. Polecenie watch monitoruje wyjście pliku i może zostać zakończone opcją -g , gdy dane wyjściowe ulegną zmianie.

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

Alex, myślę, że ten bardzo ci pomoże.

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

to polecenie nigdy nie spowoduje wpisu w pliku dziennika, ale będzie cicho grep ...

Oto znacznie lepsze rozwiązanie, które nie wymaga zapisywania do pliku dziennika, co w niektórych przypadkach jest bardzo niebezpieczne, a nawet niemożliwe.

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

Obecnie ma tylko jeden efekt uboczny, tailproces pozostanie w tle do momentu zapisania następnego wiersza w dzienniku.

Inne rozwiązania tutaj mają kilka problemów:

• jeśli proces rejestrowania jest już wyłączony lub spada podczas pętli, będą one działać w nieskończoność
• edycja dziennika, który powinien być tylko przeglądany
• niepotrzebnie zapisując dodatkowy plik
• nie dopuszczając dodatkowej logiki

Oto, co wymyśliłem, używając przykładu tomcat (usuń skróty, jeśli chcesz zobaczyć dziennik podczas jego uruchamiania):

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"
}

tailPolecenie może są umieszczane w tle i jego pid echem w greppodpowłoce. W greppodpowłoce moduł obsługi pułapki na EXIT może zabić tailpolecenie.

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

Przeczytaj je wszystkie. tldr: oddzielić zakończenie ogona od grep.

Dwie najwygodniejsze formy to

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

a jeśli masz bash

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

Ale jeśli przeszkadza ci siedzący w tle ogon, istnieje lepszy sposób niż fifo lub jakakolwiek inna odpowiedź tutaj. Wymaga uderzenia.

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

Lub jeśli to nie ogon wytwarza rzeczy,

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

Spróbuj użyć inotify (inotifywait)

Ustawiasz inotifywait dla każdej zmiany pliku, a następnie sprawdzasz plik za pomocą grep, jeśli nie znaleziono, po prostu uruchom ponownie inotifywait, jeśli znaleziono, zamknij pętlę ...

Chcesz wyjść zaraz po napisaniu wiersza, ale chcesz też wyjść po upływie limitu czasu:

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

co powiesz na to:

chociaż prawda; zrobić, jeśli [! -z $ (grep „myRegEx” myLog.log)]; następnie złam; fi; gotowy