[haiku-development] Re: A solution for all your debugging woes!

  • From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 03 May 2015 07:22:41 +0000

2 mai 2015 23:25 "kallisti5" <kallisti5@xxxxxxxxxxx> a écrit:

On 2015-05-02 11:35, Ingo Weinhold wrote:

On 02.05.2015 17:12, kallisti5 wrote:
No clue why I never thought of this.

So when you have an issue at boot, there is no guarantee
that syslog will be written to disk. (99.99% of the time it isn't)

This means you have to pull out the ol' serial cable to get kernel
logs.

I'm about to test a new boot option. "Enable synchronous syslog"

Pretty much just calls fsync on the syslog filesystem after
every syslog event.

Slow? Hell yes. However by forcing a filesystem flush after every
event we might actually have some valid log data without needing
the ol' serial cable.

There are a few issues to consider:

* The syslog mechanism is asynchronous by design. Applications and the
kernel send syslog messages to the syslog daemon which in turn writes
them to the syslog file at its own leisure.

* The most interesting syslog messages are usually kernel debug
messages which are handled asynchronously already in the kernel --
they are written to a buffer and another thread asynchronously sends
them to the syslog daemon. While making the communication with the
syslog daemon synchronous (i.e. waiting for a reply from the daemon
after it has written the message to and fsync()ed the syslog file)
could be done, making the in-kernel mechanism synchronous isn't
generally possible.

* Any boot issue that happens before the syslog daemon has been
started and prevents the syslog daemon from being started (e.g. due to
a kernel panic) will also prevent anything at all from being written
to the syslog file.

Ah, all good points. I did try this modification and it didn't work
(most likely due to how late the syslog daemon starts as you mentioned)

Depending on the particular boot issue, aggressive sync'ing may help,
but generally -- especially when the issue occurs early enough -- it
won't do much good.

I still think an aggressive kernel log sync feature could be handy.

I'm investigating some changes to see if I can figure out a debug method
of fsync in kernel that would help.

FWIW, there's a boot loader/kernel feature that allows you to see the
previous session's in-memory syslog buffer ("debug syslog") in the
boot loader menu (and even save it to a FAT partition). Alas it is not
fully reliable, since the memory range picked for the buffer may end
up being overwritten by the firmware or any initial boot loader (e.g.
grub) depending on hardware/firmware/... details that are hard to
guess. Any improvements in that area would be very welcome.

Yeah i tried that. My use case is:

1) I have a laptop without a serial port.
2) I have a laptop without a reset switch.

What about the "reboot" command in KDL? Or maybe we should also add special
keyboard commands in Linux style? (alt+sysrq+s = flush syslog to disk?). As
long as the kernel is not completely frozen, this could still work. When the
kernel is confused, you get the KDL prompt and can work from there anyway.

--
Adrien.

Other related posts: