Jak ustawić lokalizację pliku zrzutu pamięci (i nazwę)?

Korzystam z CentOS 6, próbując włączyć zrzuty pamięci dla opracowywanej przeze mnie aplikacji. Położyłem:

ulimit -H -c unlimited >/dev/null
ulimit -S -c unlimited >/dev/null

w moim profilu bash, ale zrzut pamięci nadal nie został wygenerowany (w nowym terminalu).

Zmieniłem również mój plik /etc/security/limits.conf, tak aby miękkie limity wynosiły zero dla wszystkich użytkowników.

Jak ustawić lokalizację wyjściowych plików podstawowych? Chciałem określić lokalizację i dołączyć czas generowania zrzutu jako część nazwy pliku?

Aby ustawić lokalizację zrzutów pamięci w CentOS 6, możesz edytować /etc/sysctl.conf. Na przykład, jeśli chcesz zrzutów pamięci w /var/crash:

kernel.core_pattern = /var/crash/core-%e-%s-%u-%g-%p-%t

Gdzie zmienne są:

% e to nazwa pliku
% g to gid, w którym proces działał pod
% p to pid procesu
% s to sygnał, który spowodował zrzut
% t to czas, w którym wystąpił zrzut
% u to identyfikator, w którym proces był uruchomiony

Musisz także dodać /etc/sysconfig/init

DAEMON_COREFILE_LIMIT='unlimited'

Teraz zastosuj nowe zmiany:

$ sysctl -p

Ale jest w tym zastrzeżenie. Jeśli parametr jądra kernel.core_pattern jest zawsze resetowany i zastępowany przy ponownym uruchomieniu do następującej konfiguracji, nawet jeśli wartość jest ręcznie określona w /etc/sysctl.conf:

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

W skrócie, kiedy abrtd.servicestart kernel.core_patternjest automatycznie nadpisywany przez zainstalowany system abrt-addon-ccpp. Istnieją dwa sposoby rozwiązania tego:

1. Ustawienie DumpLocationopcji w /etc/abrt/abrt.confpliku konfiguracyjnym. Katalog docelowy można określić, ustawiając DumpLocation = /var/crashw /etc/abrt/abrt.confpliku konfiguracyjnym, a sysctl kernel.core_patternwyświetlana wartość jest taka sama, ale tak naprawdę plik podstawowy zostanie utworzony w katalogu pod /var/crash.

   Również jeśli masz włączony SELinux, musisz uruchomić:

   $ semanage fcontext -a -t public_content_rw_t "/var/crash(/.*)?"  
   $ setsebool -P abrt_anon_write 1
   

   I w końcu uruchom ponownie abrtd.service:

   $ service abrtd.service restart
   

2. Zatrzymaj usługę abrtd. kernel.core_patternnie zostanie nadpisany. - (Nigdy nie testowałem).

Aby wygenerować zrzut rdzenia na Busybox, możemy dodać poniższe parametry w skrypcie inicjującym, który uruchamia nasz plik wykonywalny. Tak więc za każdym razem, gdy inicjalizujemy oprogramowanie i eksportujemy zmienne środowiskowe, możemy również skopiować poniższe wiersze do skryptu, aby zrzucić rdzeń na wypadek awarii.

Aby ustawić lokalizację zrzutów rdzenia w Busybox, możesz ustawić ścieżkę pliku rdzenia za pomocą systemu plików proc. Na przykład, jeśli chcesz zrzutów rdzenia w /tmp/crash/corefiles:

mkdir -p /tmp/crash/corefiles
chmod 775 /tmp/crash/corefiles
echo "/tmp/crash/corefiles/%e.%s.core" > /proc/sys/kernel/core_pattern

Gdzie zmienne są:

% e to nazwa pliku
% g to gid, w którym proces działał pod
% p to pid procesu
% s to sygnał, który spowodował zrzut
% t to czas, w którym wystąpił zrzut
% u to identyfikator, w którym proces był uruchomiony

Ponadto musisz ustawić rozmiar pliku podstawowego, poniższe polecenie ustawia rozmiar pliku podstawowego na nieograniczony

ulimit -c unlimited

Teraz, aby sprawdzić podstawowy rozmiar pliku ustawiony dla każdego wątku w procesie, który możemy sprawdzić za pomocą

cat /proc/<PID>/limits

Dane wyjściowe powyższego polecenia:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max open files            10000                10000                files     
Max address space         unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             31868                31868                processes 
Max locked memory         65536                65536                bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       31868                31868                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us      

Jak widać z powyższego wyjścia maksymalny rozmiar pliku rdzenia jest ustawiony na nieograniczony.

Aby uzyskać więcej informacji, odwiedź ten link. Techniki debugowania aplikacji Linux / pliki podstawowe