Czy w systemie Unix (lub Linux) istnieje mechanizm zatrzymujący zrzut pamięci w toku?


15

Powiedzmy, że (bardzo) duży proces powoduje awarię i wyrzucanie rdzenia, a przyczynę znamy z innych informacji (być może wiadomość potwierdzająca, a może coś innego).

Czy istnieje sposób, aby zatrzymać generowanie zrzutu pamięci, ponieważ w tym przypadku jest to strata?

Na przykład, czy zabicie -9 procesu zrzutu rdzenia przerwałoby generowanie pliku rdzenia?

Oczywiście, gdybyśmy z góry wiedzieli, że nie chcemy zrzutów rdzenia, moglibyśmy odpowiednio ustawić ulimit lub użyć różnych narzędzi kontroli plików rdzenia systemu operacyjnego.

Ale to pytanie dotyczy etapu „zrzutu pamięci już w toku” ...

(Na przykład wyobraź sobie, że jestem żądającym w /programming/18368242/how-to-bypass-a-2tb-core-dump-file-system-limit i nie chcę marnować 5 -6 TB miejsca na dysku :))


W systemie Linux możesz wyłączyć generowanie zrzutu pamięci ... czy może to być opcja?
krisFR

Nie - zrzuty rdzenia są ogólnie konieczne, ale szukamy sposobu na ich zatrzymanie w przypadkach, w których wiemy, na czym polega problem bez potrzeby używania rdzenia, aby zaoszczędzić czas / miejsce na dysku itp. oczywiście możemy po prostu usunąć rdzeń, gdy skończy się zrzut (lub nawet odłączyć go wcześniej), ale nie ma powodu, aby wiązać kilka gigabajtów miejsca na dysku, gdybyśmy mogli wcześniej zabić zrzut jądra.
Mike G.

Możesz użyć „cat / dev / null> <path_to_core>” w skrypcie wywołującym program, gdy spełniony jest określony warunek, tak długo, jak istnieje wpis / proc / <pid>, śpij co kilka sekund i uruchom / dev / null copy do pliku core. Spowoduje to wyzerowanie. Nie jestem pewien pełnego kontekstu pytania, ale to może zadziałać.
Schrute

Schrute, to miałoby taki sam efekt jak rozłączenie rdzenia, prawda? Miejsce na dysku i zasoby systemowe byłyby nadal zużywane, dopóki rdzeń nie zakończy pisania - rozmiar pliku po prostu nie byłby widoczny w du lub ls.
Mike G.

Zasoby tak, jednak jest to powszechna metoda radzenia sobie z dużym plikiem, takim jak plik core / log, i nie zatrzymywanie PID. To zależy tylko od celu.
Schrute

Odpowiedzi:


8

Ogólnie: nie, nie ma sposobu, aby niezawodnie zabić rdzeń rdzeniowy.

Biorąc to pod uwagę, istnieje możliwość (przynajmniej w systemie Linux) komercyjnego * NIX prawdopodobnie nie ma mowy

Możliwość polega na tym, że jądro serii 3.x jest w stanie przerwać zapisywanie plików. Jedną z możliwości jest znalezienie wątku, który wykonuje zrzut i wielokrotnie wysyłać do niego SIGKILL, dopóki się nie powiedzie.

Ta seria poprawek rozwiązuje problem do pewnego poziomu.

Inną możliwością jest użycie alternatywnej składni dla coredump_pattern. Podręcznik mówi, że od wersji 2.6.19 zamiast wzorca można użyć potoku i programu (z parametrami), który będzie obsługiwał zrzut. Ergo będziesz miał kontrolę nad tym, który zrzut zostanie zapisany w miejscu (/ dev / null jest oczywistym kandydatem na twoje bezużyteczne rdzenie).

Ta łatka również zasługuje na uwagę: http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-06/msg00918.html


Dzięki zeridon - to zdecydowanie najlepsza jak dotąd odpowiedź.
Mike G.

Pomyślałbym, że jeśli użyjesz mechanizmu rurociągów, możesz po prostu wyjść bez odczytywania danych potoku, jeśli wiesz, że nie jest to coś, co chcesz zachować (chyba że zepsute rury stwarzają inny problem ... musiałby to przetestować.)
Alexis Wilke


-1

Wygląda na to, że możesz uruchomić ulimit -c (zakładając, że używasz bash), aby ograniczyć rozmiar zrzutu pamięci.

Zobacz: /ubuntu/220905/how-to-remove-limit-on-core-dump-file-size

i

http://ss64.com/bash/ulimit.html


1
Kerry, jak powiedziałem w OP, „Oczywiście, gdybyśmy z góry wiedzieli, że nie chcemy zrzutów pamięci, moglibyśmy odpowiednio ustawić ulimit lub użyć różnych narzędzi kontroli plików w systemie operacyjnym”. Próbuję sprawdzić, czy istnieje sposób na zatrzymanie zrzutu pamięci, gdy już zaczął się on dla bardzo dużego zadania (aby zaoszczędzić czas / miejsce na dysku / zasoby).
Mike G.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.