[systemd-devel] Can coredumpctl work independent of journald?

[Lennart Poettering]

On Wed, 11.05.16 20:31, P.R.Dinesh (pr.dinesh at gmail.com) wrote:

> I have set the journald to be persistant and limit its size to 40MB.
> I had a process coredumped and the coredump file is found in
> /var/log/systemd/coredump
> 
> When I run coredumpctl this coredump is not shown.
> 
> Later I found that the core dump log is missing from the Journal ( the
> journal got wrapped since it reached the size limitation).
> 
> I think coredumpctl depends on journal to display the coredump.  Can't it
> search for the coredump files present in the coredump folder and list those
> files?

We use the metadata and the filtering the journal provides us with,
and the coredump on disk is really just secondary, external data to
that, that can be lifecycled quicker than the logging data. We extract
the backtrace from the coredump at the momemt the coredump happens,
and all that along with numerous metadata fields is stored in the
journal. In fact storing the coredump is optional, because in many
setups the short backtrace in the logs is good enough, and the
coredump is less important.

So, generally the concept here really is that logs are cheap, and thus
you keep around more of them; and coredumps are large and thus you
lifecycle them quicker. If I understand correctly what you want is the
opposite: you want a quicker lifecycle for the logs but keep the
coredumps around for longer. I must say, I am not entirely sure where
such a setup would be a good idea though... i.e. wanting persistent
coredumps but volatile logging sounds a strange combination to
me... Can you make a good case for this?

But yeah, we really don't cover what you are asking for right now, and
I am not sure we should...

> Also can I launch the coredumpctl gdb by providing a compressed core
> file.

If you configure systemd-coredump to store the coredumps compressed
(which is in fact the default), then "coredumpctl gdb" will implicitly
decompress them so that gdb can do its work.

Lennart

-- 
Lennart Poettering, Red Hat