<div dir="ltr">Additionally can we improve the journal log rotate system to keep the higher severity messages (like coredump) for longer duration and remove lower priority messages to get spaces.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 8:15 AM, P.R.Dinesh <span dir="ltr"><<a href="mailto:pr.dinesh@gmail.com" target="_blank">pr.dinesh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you Lennart, <div>I would like to explain my system scenario.</div><div><br></div><div>We are using systemd version 219. (Updating to 229 is in progress).</div><div><br></div><div>Configured for persistent storage for both Journal and Coredump (Coredump is stored externallly)</div><div><br><div>The logs and coredump are stored in another partition "/var/diagnostics/logs" and "/var/diagnostics/coredump". We do symbolic link between the /var/lib/systemd/coredump and logs to those folders. </div><div><br></div><div>Coredump and journald is configured to utilized upto 10% of the disk space(total disk space is ~400MB) which would allocate 40MB to journal logs and 40MB to coredump. For some reason (under investigation) some of our daemons are generating too much logs which makes the journald to reach the 40MB limit within 6 hours. Hence journald starts wrapping around. Meanwhile some daemons have also crashed and core dumped. </div></div><div><br></div><div>Now when I do coredumplist, none of those coredumps are shown. </div><div><br></div><div>Also I tried launching the coredumpctl with the coredump file both using the pid name as well as using the coredump file name. Since we dont have the journal entry coredumpctl is not launching them, can we atleast have the coredumpctl launch the gdb using the core dump file name?</div><div><br></div><div><div>[prd@localhost ~]$ coredumpctl gdb core.lshw.1000.9bb41758bba94306b39e751048e0cee9.23993.1462871523000000.xz</div><div>No match found.</div><div>[prd@localhost ~]$ coredumpctl gdb 23993</div><div>No match found.</div></div><div><br></div><div><br></div><div>In summary, the frequency of logs are higher and the frequency of core dumps are very less in our system which leads to the loss of coredump information.<br></div><div><br></div><div>I am thinking of two solutions here</div><div>1) Enhance coredumpctl to launch the gdb using the coredump file name</div><div>2) Store the Journal logs for coredump seperately from other journal logs so that they could be maintained for long duration (is this feasible?)</div><div><br></div><div>Thank you</div><div>Regards,</div><div>Dinesh</div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, May 11, 2016 at 10:25 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On Wed, 11.05.16 20:31, P.R.Dinesh (<a href="mailto:pr.dinesh@gmail.com" target="_blank">pr.dinesh@gmail.com</a>) wrote:<br>
<br>
> I have set the journald to be persistant and limit its size to 40MB.<br>
> I had a process coredumped and the coredump file is found in<br>
> /var/log/systemd/coredump<br>
><br>
> When I run coredumpctl this coredump is not shown.<br>
><br>
> Later I found that the core dump log is missing from the Journal ( the<br>
> journal got wrapped since it reached the size limitation).<br>
><br>
> I think coredumpctl depends on journal to display the coredump. Can't it<br>
> search for the coredump files present in the coredump folder and list those<br>
> files?<br>
<br>
</span>We use the metadata and the filtering the journal provides us with,<br>
and the coredump on disk is really just secondary, external data to<br>
that, that can be lifecycled quicker than the logging data. We extract<br>
the backtrace from the coredump at the momemt the coredump happens,<br>
and all that along with numerous metadata fields is stored in the<br>
journal. In fact storing the coredump is optional, because in many<br>
setups the short backtrace in the logs is good enough, and the<br>
coredump is less important.<br>
<br>
So, generally the concept here really is that logs are cheap, and thus<br>
you keep around more of them; and coredumps are large and thus you<br>
lifecycle them quicker. If I understand correctly what you want is the<br>
opposite: you want a quicker lifecycle for the logs but keep the<br>
coredumps around for longer. I must say, I am not entirely sure where<br>
such a setup would be a good idea though... i.e. wanting persistent<br>
coredumps but volatile logging sounds a strange combination to<br>
me... Can you make a good case for this?<br>
<br>
But yeah, we really don't cover what you are asking for right now, and<br>
I am not sure we should...<br>
<span><br>
> Also can I launch the coredumpctl gdb by providing a compressed core<br>
> file.<br>
<br>
</span>If you configure systemd-coredump to store the coredumps compressed<br>
(which is in fact the default), then "coredumpctl gdb" will implicitly<br>
decompress them so that gdb can do its work.<br>
<span><font color="#888888"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div><div dir="ltr">With Kind Regards,<br>Dinesh P Ramakrishnan<br></div></div>
</span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">With Kind Regards,<br>Dinesh P Ramakrishnan<br></div></div>
</div>