[haiku-development] Re: A solution for all your debugging woes!
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 02 May 2015 18:35:50 +0200
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.
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.
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.
CU, Ingo
Other related posts:
