[systemd-devel] systemd-journald missing crash logs

Lennart Poettering lennart at poettering.net
Wed Jan 24 08:59:00 UTC 2018


On So, 21.01.18 19:53, Farzad Panahi (farzad.panahi at gmail.com) wrote:

> > On Fr, 12.01.18 16:13, Farzad Panahi (farzad.panahi at gmail.com) wrote:
> >
> > > I am running Arch-ARM on RPi3. I have noticed when system crashes I
> > cannot
> > > find any related crash log in journal logs.
> >
> > What specifically is a "crash" supposed to mean?
> >
> >
> 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.

Well, that sounds more like a "hang" than what I would call a
"crash". Now depending on the nature of the hang this might have the
effect that the whole system simply freezes, and if that happens, then
the journal can't do a thing either anymore...

> > delivered. I am not sure what "crash" is supposed to mean, but are you
> > sure that at least one LOG_CRIT/LOG_ALERT/LOG_EMERG message is
> > delivered to userspace about that?
> >
> 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.

Well, that really depends on the nature of the hang. if the kenrel
just locks up, then userspace won't get scheduled anymore, and hence
no userspace logger in this world would help you tracking this down...

> So I think one of the following is happening:
> a) no log is generated at the time of crash (I think this is
> unlikely)
> b) log is generated but does not reach journald
> c) log reaches journald but journald does not get a chance to persist it
> d) journald persists the log but somehow the log is corrupted and ignored
> 
> 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?

This is not a journal-specific issue: had kernel lockups are hard to
debug. Without direct console access you are in trouble. make sure to
turn on all printk logging directlyto consoleto track things like that
down... But at that point it's probably better to ask the kernel
community for help...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list