<div dir="ltr">Thank you Lennart, <div><br></div><div>This sounds as an interesting proposal.</div><div><br></div><div>I am interested in the below enhancement which would give us fine control on what is stored persistantly </div><div>"<span style="color:rgb(0,0,0);font-size:12.8px">(along with this feature we should probably also add support for</span></div><span style="color:rgb(0,0,0);font-size:12.8px">storing low-priority messages in /run only, so that debug stuff is</span><br style="color:rgb(0,0,0);font-size:12.8px"><span style="color:rgb(0,0,0);font-size:12.8px">kept around only during runtime, but not after)"</span><div><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.8px">I am proposing for a user configuration parameter where he can specify a minimum severity level for storing persistently.  Any logs below that severity would just stay in runtime only. </span></font></div><div><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.8px">I seek your advice and request you to provide me some pointers on designing this feature.  </span></font></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 11:21 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 12.05.16 08:15, P.R.Dinesh (<a href="mailto:pr.dinesh@gmail.com">pr.dinesh@gmail.com</a>) wrote:<br>
<br>
> Thank you Lennart,<br>
> I would like to explain my system scenario.<br>
><br>
> We are using systemd version 219. (Updating to 229 is in progress).<br>
><br>
> Configured for persistent storage for both Journal and Coredump (Coredump<br>
> is stored externallly)<br>
><br>
> The logs and coredump are stored in another partition<br>
> "/var/diagnostics/logs" and "/var/diagnostics/coredump".  We do symbolic<br>
> link between the /var/lib/systemd/coredump and logs to those folders.<br>
><br>
> Coredump and journald is configured to utilized upto 10% of the disk<br>
> space(total disk space is ~400MB) which would allocate 40MB to journal logs<br>
> and 40MB to coredump.  For some reason (under investigation) some of our<br>
> daemons are generating too much logs which makes the journald to reach the<br>
> 40MB limit within 6 hours.  Hence journald starts wrapping around.<br>
> Meanwhile some daemons have also crashed and core dumped.<br>
><br>
> Now when I do coredumplist, none of those coredumps are shown.<br>
<br>
</span>I see.<br>
<span class=""><br>
> Also I tried launching the coredumpctl with the coredump file both using<br>
>  the pid name as well as using the coredump file name.  Since we dont have<br>
> the journal entry coredumpctl is not launching them,  can we atleast have<br>
> the coredumpctl launch the gdb using the core dump file name?<br>
<br>
</span>The coredumps are simply compressed, use the xz tools to decompress<br>
them. Note however, that the xz file format generated by the xz<br>
libraries was incomptible with the xz tool for a long time, which is<br>
why the xz support in the journal and the coredumping code was<br>
experimental until v229. Make sure to upgrade to v229 if you want to<br>
decompress the coredumps with the normal "unxz".<br>
<span class=""><br>
><br>
> [prd@localhost ~]$ coredumpctl gdb<br>
> core.lshw.1000.9bb41758bba94306b39e751048e0cee9.23993.1462871523000000.xz<br>
> No match found.<br>
> [prd@localhost ~]$ coredumpctl gdb 23993<br>
> No match found.<br>
<br>
</span>If you have v229 this should work:<br>
<br>
    unxz < /var/lib/systemd/coredump/core.lshw.1000.9bb41758bba94306b39e751048e0cee9.23993.1462871523000000.xz > ~/coredump<br>
    gdb ~/coredump<br>
    …<br>
<span class=""><br>
> In summary, the frequency of logs are higher and the frequency of core<br>
> dumps are very less in our system which leads to the loss of coredump<br>
> information.<br>
><br>
> I am thinking of two solutions here<br>
> 1) Enhance coredumpctl to launch the gdb using the coredump file name<br>
> 2) Store the Journal logs for coredump seperately from other journal logs<br>
> so that they could be maintained for long duration (is this<br>
> feasible?)<br>
<br>
</span>A feature that has been requested before is that we add<br>
priority-sensitive rotation to the journal: keep error messages with<br>
levels of ERROR or higher around for longer than INFO and lower or<br>
so. Given that the coredumps are logged at CRIT level, this would<br>
cover your case nicely.<br>
<br>
However, that's a feature request only, and I think it would make<br>
sense to have, but nobody hacked that up yet.<br>
<br>
(along with this feature we should probably also add support for<br>
storing low-priority messages in /run only, so that debug stuff is<br>
kept around only during runtime, but not after)<br>
<div class="HOEnZb"><div class="h5"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</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>