[systemd-devel] Skipping temporary coredump file during coredump generation

[P.R.Dinesh]

Thank you for the insight.
Shall I propose the patch with the following behaviour.

Check if "backtrace is enabled" or "compression is not enabled or not
supported"
Then store the temporary uncompressed file.
If not skip the uncompressed file generation.

if( backtrace_enabled || ( compression_not_enabled ||
compress_not_supported))
{
  generate and store uncompressed coredump
}
else
{
  skip uncompressed coredump file, compress the STDIN COREFILE.
}




On Sat, 3 Dec 2016 at 23:46 Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl>
wrote:

> On Fri, Dec 02, 2016 at 05:53:59PM +0000, P.R.Dinesh wrote:
> > During coredump generation I could find a temporary uncompressed file
> > getting generated from the corefile and written to the harddisk, later
> this
> > file is getting compressed (if compression was enabled) and then the file
> > coredump file is stored and this temporary file is removed.
>
> We write the uncompressed file to disk to generate the backtrace.
> If we aren't doing that, we can just compress on-the-fly.
>
> > I have a process whose memory consumption is typically around 5GB, it
> > generates around 13GB of uncompressed coredump ( coredump_filter = 0x33).
> > Later this file is compressed to 20MB and the uncompressed file is
> removed.
> > I have set the
> > ProcessSizeMax=16GB
> > ExternalSizeMax= 16GB
> > But sometimes my disk doesn't have sufficient space to store this
> temporary
> > file, hence systemd-coredump aborts the coredump processing.
> >
> > Is it possible to skip this temporary file generation and generate the
> > compressed file directly from the Corefile passed through STDIN?
>
> We could be smarter, and if we see that there isn't enough disk space
> to store the uncompressed core file, skip this step, and immediately
> try to write compressed data. I don't know how complicated that would be:
> we write the core either to the file or to the journal, so the code is
> pretty complicated. Patches are welcome ;)
>
> Zbyszek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20161204/6d3bb680/attachment.html>