Czy istnieje sposób na usunięcie pierwszych Nwierszy z dziennika, który jest aktywnie dołączany przez aplikację?
Czy istnieje sposób na usunięcie pierwszych Nwierszy z dziennika, który jest aktywnie dołączany przez aplikację?
Odpowiedzi:
Nie, systemy operacyjne takie jak Linux i jego systemy plików nie przewidują usuwania danych z początku pliku. Innymi słowy, punkt początkowy przechowywania pliku jest ustalony.
Usuwanie wierszy z początku pliku jest zwykle realizowane przez zapisanie pozostałych danych w nowym pliku i usunięcie starego. Jeśli program ma stary plik otwarty do zapisu, usunięcie tego pliku jest odraczane do momentu zamknięcia pliku przez aplikację.
Jak zauważyli komentatorzy, z powodów podanych w poprzednim zdaniu zazwyczaj musisz koordynować czyszczenie plików dziennika z programami, które zapisują dzienniki. Dokładnie jak to zrobisz, zależy od programów. Niektóre programy zamykają i ponownie otwierają swoje pliki dziennika, gdy wyślesz im sygnał (np. HUP), co może być użyte, aby zapobiec zapisywaniu zapisów dziennika w „usuniętym” pliku dziennika, bez zakłócania usługi.
Istnieje wiele narzędzi do zarządzania rozmiarem plików dziennika, na przykład logrotate
Niektóre programy mają własne narzędzia. Na przykład serwer Apache zawiera narzędzie rotatelogs .
Myślę, że to zadanie można osiągnąć sed
sed -i '1,10d' myfile
usunie linie od 1 st do 10 th postaci linii pliku.
Myślę, że każdy powinien przynajmniej rzucić okiem na te wkładki sed 1 .
Pamiętaj, że nie działa to w przypadku plików dziennika, do których aplikacja jest aktywnie dołączana (jak podano w pytaniu).
sed -iutworzy nowy plik i „usunie” zapisywany plik. Większość aplikacji będzie nadal zapisywać zapisy dziennika w usuniętym pliku dziennika i będzie nadal wypełniać miejsce na dysku. Nowy, obcięty plik dziennika nie zostanie dołączony. Spowoduje to ustanie dopiero po ponownym uruchomieniu aplikacji lub w inny sposób zostanie zasygnalizowane zamknięcie i ponowne otwarcie plików dziennika. W tym momencie w nowym pliku dziennika pojawi się luka (brakujące zapisy dziennika), jeśli między użyciem sed a restartem aplikacji wystąpi jakakolwiek rejestrowalna aktywność.
Bezpiecznym sposobem na to byłoby zatrzymanie aplikacji, użycie sed do obcięcia dziennika, a następnie ponowne uruchomienie aplikacji. Takie podejście może być nieakceptowalne w przypadku niektórych usług (np. Serwer WWW o wysokiej przepustowości i wysokich wymaganiach dotyczących ciągłości usług)
sed -itworzy nowy plik z edytowaną treścią, a stary jest usuwany, więc nie edytujesz aktywnego pliku: $ ls -i --- 6823554 testfile --- $ sed -i 's/test/final/' testfile --- $ ls -i --- 6823560 testfile------ Sprawdź, jak sed -idziała. Dlaczego ta zła odpowiedź ma tak wiele pozytywnych opinii?
Nie. Rozwiązaniem tego ogólnego problemu wzrostu pliku dziennika jest rotacja dziennika. Obejmuje to regularne (zwykle co tydzień lub co tydzień) przenoszenie istniejącego pliku dziennika do innej nazwy pliku i rozpoczynanie od nowa z pustym plikiem dziennika. Po pewnym czasie stare pliki dziennika są wyrzucane.
Zobacz: http://www-uxsup.csx.cam.ac.uk/~jw35/courses/apache/html/x1670.htm
To jest odpowiedź , a nie rozwiązanie. Nie ma rozwiązania tego pytania. Pytający wyraźnie stwierdza: „z dziennika, który jest aktywnie dołączany przez aplikację”. Możesz przeczytać dalej, aby zrozumieć więcej, i przejść do końca, aby uzyskać sugestię na podstawie mojego domniemania, dlaczego ten kod nie przestrzega najlepszych praktyk w zakresie rejestrowania.
Żeby było jasne: inne „odpowiedzi” tutaj oferują fałszywą obietnicę . Żadna zmiana nazwy nie zmusi aplikacji do korzystania z nowego pliku. Najbardziej przydatne informacje są ukryte w komentarzach do tych nieprawidłowych odpowiedzi.
Pliki AKTYWNE nie są rodzajem kontenera, w którym po prostu umieszczasz dane. Nazwa pliku wskazuje JEDEN i-węzeł (początek pliku), a każdy i-węzeł ma wskaźnik do innego i-węzła (jeśli jest więcej danych). Oznacza to, że ciągły zapis do pliku zawiera ciągły strumień i-węzłów, a to, co myślisz o „pliku”, jest w rzeczywistości sekwencją logów i-węzłów.
Wyobraź sobie, że śledzisz kogoś w Mapach Google, a ta osoba może się teleportować w dowolnym miejscu na świecie, w dowolnym momencie, i próbujesz połączyć te kropki.
Narzędzie „obcinaj” w systemie Linux może odrzucić dane na końcu pliku, po prostu idąc po drzewie i-węzłów i (w wyznaczonym miejscu / rozmiarze) odrzuci wszystkie kolejne wskaźniki na stosie. Wykonanie operacji odwrotnej - odrzucenie danych na początku pliku - byłoby tak strasznie złożonym i ryzykownym procesem przepisywania drzewa i- węzłów w czasie rzeczywistym, że nikt nie napisze takich narzędzi dla społeczeństwa, ponieważ często zawodziły i prowadziły do utrata danych. W inodes wiki jest krótki, ale wyjaśnia niektóre z tych pojęć.
** Moja rada: odwróć ten problem - DLACZEGO ta aplikacja zachowuje się w ten sposób? Istnieje wiele sprawdzonych metod rejestrowania, ale często są one powiązane z tym, czym faktycznie jest system rejestrowania (syslog itp.). Zasadniczo aplikacja powinna „zwolnić” swój uchwyt do pliku, więc logrotate (itp.) Może obsłużyć dalsze przetwarzanie starych danych.
Ilekroć słyszę „do AKTYWNEGO pliku dziennika”, natychmiast proszę tę osobę, aby opowiedziała mi „specjalną historię” kryjącą się za tą aplikacją. Zwykle jest to „rezygnacja programisty i nie możemy zmienić kodu. To faktycznie jest odwrotność bezpieczeństwa, ma swój własny zestaw ryzyk. Ale dostaję rozwiązanie, które pozwala uniknąć dotykania kodu źródłowego. Jeśli to jest W takim przypadku potrzebne jest bardziej szczegółowe pytanie.
Otwieranie w wysublimowanym tekście Usuwanie wierszy i zapisywanie pliku działa jakoś, nawet jeśli plik jest dołączany, ale przyszedłem tutaj, aby poszukać rozwiązania dla wiersza polecenia, więc zostawię to działające, ale bezużyteczne rozwiązanie tutaj !!
Może skopiuj, obetnij, przywróć kopię do rozmiaru = 0 obcięcia i usuń kopię?
Lepiej jeszcze od ogona do kopiowania ogona, obcinania oryginału, konkatowania kopiowania ogona na oryginał.
Otrzymujesz linie w dzienniku na długości ogona, więc lepiej niż limit długości bajtów.
Zmiana szczegółów z komentarza:
Najpierw mamy skrypt logujący w Python3, co tylko chcesz
from time import sleep
idx = 0
while 1 == 1:
idx = (idx + 1)
lf = open('tailTrunc.log', 'a')
lf.write("line to file " + str(idx) + '\n')
lf.close()
sleep(0.01)
Następnie mamy nasz obcinacz
#!/usr/bin/env bash
trap "kill 0" EXIT
rm tailTrunc.log
touch tailTrunc.log
python3 logLoop.py &
loggerPID=$!
sleep 1
kill -STOP $loggerPID
tail -10 tailTrunc.log > trimEnd.log
truncate -s 0 tailTrunc.log
kill -CONT $loggerPID
sleep 1
trimEnd.log pokazuje od 80 do 89
log pokazuje 90 do końca
W każdym razie, gdzie jest wola, istnieje sposób.
Wiele bardziej skomplikowanych przykładów konsolidatorów oraz tego, jak strumień zapisu jest otwierany lub zamykany, może wymagać dostosowania na rdzeń procesora itp. Po prostu wstrzymaj pisanie i ustaw kolejkę, jeśli możesz w rejestratorze procesu rejestrowania itp.