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.z...@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
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
