<div dir="ltr">Hi Lennart - Thanks for your comments.<div> </div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 15, 2018 at 4:11 AM, 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:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Fr, 12.01.18 16:13, Farzad Panahi (<a href="mailto:farzad.panahi@gmail.com">farzad.panahi@gmail.com</a>) wrote:<br>
<br>
> I am running Arch-ARM on RPi3. I have noticed when system crashes I cannot<br>
> find any related crash log in journal logs.<br>
<br>
</span>What specifically is a "crash" supposed to mean?<br>
<br></blockquote><div><br></div><div>Crash in my case means that the box becomes unresponsive. Meaning that I cannot ssh to it anymore until it is power cycled. I do not know what is happening to the box because there are no logs at the time of crash. Logs start rolling after the reboot. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
journald syncs to disk whenever a log message above LOG_ERR is<br>
delivered. I am not sure what "crash" is supposed to mean, but are you<br>
sure that at least one LOG_CRIT/LOG_ALERT/LOG_EMERG message is<br>
delivered to userspace about that?<br>
<span class="gmail-"><br></span></blockquote><div>I am not sure about that. I just assume if some critical issue is happening such that it makes the system unresponsive, then there should be high priority logs associated with it. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> > Since the syslog component of systemd, journald, does not flush its<br>
> > logs to disk during normal operation, these logs will be gone when the<br>
> > machine is shut down abnormally (power loss, kernel lock-ups, ...). In<br>
> > the case of kernel lock-ups, it is pretty important to have some<br>
> > kernel logs for debugging. Until journald gains a configuration option<br>
> > for flushing kernel logs, rsyslog can be used in conjunction with<br>
> > journald.<br>
<br>
</span>As mentioned above, we wil sync immediately when a<br>
LOG_CRIT/LOG_ALERT/LOG_EMERG log message is seen. We'll also sync on<br>
normal log messages with a delay of 5min at max:<br>
<br>
<a href="https://github.com/systemd/systemd/blob/master/src/journal/journald-server.c#L1440" rel="noreferrer" target="_blank">https://github.com/systemd/<wbr>systemd/blob/master/src/<wbr>journal/journald-server.c#<wbr>L1440</a><br>
<br>
if you get get a hard kernel lockup for some reason then this all is<br>
useless however, as userspace won't even get the opportunity to write<br>
anything to disk then... And it doesn't matter if userspace runs<br>
journald or rsyslog.<br>
<br></blockquote><div><br></div><div>So I think one of the following is happening: </div><div>a) no log is generated at the time of crash (I think this is unlikely) </div><div>b) log is generated but does not reach journald </div><div>c) log reaches journald but journald does not get a chance to persist it</div><div>d) journald persists the log but somehow the log is corrupted and ignored</div><div><br></div><div>I think scenario "c" is the most probable one in my case. So I just want to confirm if kernel panics, then most probably I will not see any logs in my log files? Is there a recommended workaround to debug such cases? </div></div><br></div></div>