move logs to UMS about kfmon

[NiLuJe]

It's next to impossible, because we're still alive when Nickel exports it over USBMS... and in fact, we're logging that onboard got unmounted as it is happening ;).

So we effectively can't log to USBMS at that moment, because that would be Bad. And, AFAIK, we can't (easily) close the log file before it happens, and then re-open it after. (We might be able to get a hint that things are about to go down with udev events, but that's a huge mess/intrusive, and I don't think the timing plays in our favor here, and even how non-messy it'd be from inside a C app).

TL;DR: We can react to it, and it's what we do to handle our inotify watches, but for logging, we'd have to something before the fact, not after ;).

So, yeah, I'd like to, but it's a complex beast ;). Hence the option to log to the syslog instead, because at least that's standard (even if it's a ring buffer never making it to disk on Kobo, you can still logread).

That doesn't help much until someone comes up with a front-end for logread on device, but, hey :D.

[NiLuJe]

Although... It's given me a terrible idea: a watch that plays with FBInk, tail -n, and the logfile to litter your screen with it :D.

That only helps if KFMon is somewhat functional, though.

And it'd make my life easier if FBInk handled linefeeds, but I'm not sure if I want to mess with the line-breaking/formatting code again... :D.

[NiLuJe]

Because without handling linefeeds, fbink "$(tail -n 25 /usr/local/kfmon/kfmon.log)" looks like this :D

[NiLuJe]

It'd look like this w/ LF handling, although my WIP code is buggy as hell, so, meh.

fbink "$(tail -n 15 /usr/local/kfmon/kfmon.log)" -y 1 -h

[pazos]

Thanks for the (verbose) feedback 👍

And nice tool this fbink of yours 😃 I think it would fit in koreader. Since the last time I checked they bundled dropbear, so I think add a few kbs more isn't a problem.

[NiLuJe]

Verbose is my middle name ;p.

If/Until I manage to get linefeeds handled in a satisfying way, 05d9bf8 implements a massively crappy workaround to do the job ;).
It currently relies on unreleased FBInk code, because I did catch a genuine bug thanks to this ;).

As for KOReader, one actual use-case would be progress feedback when uncompressing updates, like I implemented on Kindle via eips.
c.f., https://github.com/koreader/koreader/blob/master/platform/kindle/koreader.sh#L88 & https://github.com/koreader/koreader/blob/master/platform/kindle/kotar_cpoint

[NiLuJe]

Well, it's not too bad... There's a bit of a race between the reader and FBInk for who gets to draw first, but right now, and possibly because it's an image, the reader does another refresh a few seconds after opening, so you get the gist of it magically reappearing.

Plus, that leaves you time to admire my awesome handcrafted icon. :D.

[NiLuJe]

Noope, not a race at all, turned out to be good old I/O buffering.

[NiLuJe]

Now that 1.2.0 is finally out, that's probably as good as handling this is going to get ;).

[NiLuJe]

In case you really need logs on the userstore, one possibly alternative may be:

use_syslog = 1

in /mnt/onboard/.adds/kfmon/config/kfmon.ini

combined with

[DeveloperSettings]
EnableDebugServices=true

in /mnt/onboard/.kobo/Kobo/Kobo eReader.conf

Since that dumps both dmesg & the syslog in /mnt/onboard/.kobo ... ;).