[systemd-devel] FixMe need a coredump HOOK

Leslie Zhai xiangzhai83 at gmail.com
Sun Jun 8 05:49:10 PDT 2014


Hi Zbyszek,

Thanks for your reply :)

OK, it is enough to collect user space coredump info for bug reporter 
frontend :)

1. const char *field, the second parameter of sd_journal_get_data, is 
able to set filter to limit the entries, isn't it?

2. I simply init pollfd struct with fds[0].fd = sd_journal_get_fd(m_j) 
&& fds[0].events = sd_journal_get_events(m_j)
https://github.com/AOSC-Dev/FixMe/blob/master/test/test_systemd_journal.c#L22

But my systemd_journal testcase print out no such file or directory error
COREDUMP=ELF

Please someone give me some advice, thanks a lot!

Regards,
Leslie Zhai <xiang.zhai at i-soft.com.cn>


On 2014年06月08日 05:00, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> the coredump machinery provided by the kernel only works for
> user space processes. Kernel faults usually end in a traceback
> being printed to the console and are handled differently.
>
> To receive information about past and future coredumps stored
> in the journal you need to:
>
> 1. Add a filter which limits entries to MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
> (I think you already have this)
>
> 2. retrieve a journal file descriptor which can be used for
> polling with sd_journal_get_fd()
>
> 3. loop over existing entries
> (You also seem to have this implemented)
>
> 4. establish a loop which will poll for journal changes.
> sd_journal_wait() implements such a loop, but if you want to run this
> code from a different event loop, you should add the file descriptor
> received from sd_journal_get_fd() to this external event loop. This is
> described in some detail in the sd_journal_wait(3) man page.
>
> You can use 'journalctl -f MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1'
> as a general guide.
>
> HTH,
> Zbyszek



More information about the systemd-devel mailing list