What where the problems (i'm curious)?
Regarding the problems, read discussion at bug 14838 (and earlier discussion
also at 14227)
https://dev.openwrt.org/ticket/14838
There is no actual problem in the logging itself, but the problem is
apparently a 64 kB ubus message maximum size set in ubusmsg.h.
http://nbd.name/gitweb.cgi?p=luci2/ubus.git;a=blob;f=ubusmsg.h;h=c9b92e7132edb039618a21921bc695396a722b0e;hb=4e82a1fabb87b5e3c948a792e16b0fac3702721b#l22
Logread sends a "log read request" via ubus to logd. Logd fills a message
buffer with the required lines and returns it via ubus to logread, which then
displays it for the user.
As logd adds quite a lot cleartext headers to each log line item in the
blobmsg returned via ubus to logread, the 64 kB limit can be easily exceeded.
With 48 kB log size (binary contents), the blob being returned can easily be
over 90 kB.
I think it is a waste of resources to double the log size with a long
cleartext header for each log line when there is a size constraint for the
total message size (and while maintaining most of the log content still in
binary format at this point).
In my own build I have increased the logsize to 30 kB (defined in syslog.c in
ubox) , as then with the added cleartext headers the "log message" should
still stay under 64 kB.
> Maybe logread should have an option to dump current buffer in the -F file?
During my debugging I used that approach to find out where the failure
actually happened. Logd is nicely able to write to a file, but currently the
log parsing routine is in logread, so logd itself is has only the binary
contents of the log.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
