Embora eu tenha encontrado / var / lib / systemd / coredump / * para ser extremamente útil quando o gdb não dá as respostas certas, eu não fui capaz de descobrir a lógica por trás dele e o que existia antes dele, em a visão de mundo do sysvinit.
Eu me deparei com isso recentemente, já que tenho recebido falhas de segmentação em alguns softwares, mas executá-las no gdb não obteve a saída desejada. Executando através de / var / lib / systemd / coredump / encontrou os arquivos perdidos e foi capaz de executar o coredumpctl em alguns deles enquanto o resto foi capaz de desarquivar os arquivos lz4 e executá-los no gdb e obter os backtraces.
Qualquer história, lógica seria legal.
Embora as páginas man do systemd-coredump, coredumpctl e mesmo journalctl forneçam pistas sobre como elas devem ser usadas, não dizem nada sobre a lógica ou o raciocínio / histórico por trás dela.
As interfaces parecem focadas em usar o coredumpctl para iniciar o gdb no core dump.
As origens parecem ser de v39 com foco em colocar metadados no journalctl.
Mais tarde, eles convergiram para abrt receberam as mesmas mensagens (estavam sendo mescladas no momento difícil / rejeitado ?).
Seu desenvolvimento ainda parece ser um ano após o lançamento e apport teve um número significativo de lançamentos , por isso parece um NIH, infelizmente.