Brak zrzutów po ostatnich aktualizacjach systemd?

Gdy uruchamiam program, nad którym pracuję, kończy się niepowodzeniem, pojawia się następujący komunikat:

...
Aborted (core dumped)

Jednak nie zostanie utworzony zrzut pamięci. Zrzuty rdzenia zostały napisane wcześniej i nie pamiętam, że zmieniłem coś z tym związanego.

Kiedy biegnę ulimit -a, wracam,

$ ulimit -a
core file size          (blocks, -c) unlimited
...

Inne punkty,

• Zweryfikowałem, że mój użytkownik może tworzyć pliki w bieżącym katalogu.
• Czytam o /proc/sys/fs/suid_dumpable. Obecnie jest ustawiony na 0 na moim komputerze. Próbowałem zmienić to na 1 lub 2, ale bez różnicy.
• Próbowałem również uruchomić program jako root, ale to też nie miało znaczenia.

Niestety nie pamiętam, kiedy mogłem wyprodukować ostatni udany zrzut pamięci.

Od docs na coredump.conf,

Aby wyłączyć plik konfiguracyjny dostarczony przez dostawcę, zalecanym sposobem jest umieszczenie dowiązania symbolicznego /dev/nullw katalogu konfiguracyjnym w /etc/pliku o takiej samej nazwie jak plik konfiguracyjny dostawcy.

sudo ln -s /dev/null /etc/sysctl.d/coredump.conf
sudo systemd-sysctl 

Od systemd, rzeczy są zarządzane inaczej.

Możesz użyć coredumpctlpolecenia do odzyskania zrzutu pamięci lub uruchomienia na nim gdb. Jest to „systemowo zatwierdzona” metoda radzenia sobie z nimi. : - /

W pewnym sensie fajnie jest, gdy systemd przechwytuje wszystkie te rzeczy, ponieważ po pewnym czasie usunie je automatycznie, a także ułatwia przesyłanie zrzutów awaryjnych w celu zgłaszania błędów.

Była to jednak wstrząsająca zmiana, która nie wpłynęła na sposób powiadamiania ani podpowiedzi dla osób, które wiedziały, jak działają rdzeniowce, zanim zaangażował się systemd. Nawet upuszczenie pliku o nazwie „core.pid.txt” z instrukcjami, jak użyć coredumpctl, aby uzyskać zrzut rdzeniowy, a także jak wyłączyć tworzenie .txtplików, byłby bardzo pomocny, nawet jeśli te zaśmiecałyby również system plików na jakiś czas.