Closed rufferson closed 8 years ago
abranson
commented
8 years ago We've had a few requests that required logs, but I'd rather not write text logs to flash as that's generally avoided and discouraged. Could we capture it in RAM, and convert the packaging action into a start logging and stop/send?
I'm not sure of the details, but I think the Pebble SDK tool does a lot of expansion of those logs. If that's true then I don't think we could do anything useful with them.
rufferson
commented
8 years ago yes, was also thinking about it over the morning when my pebble was showing disconnected despite daemon was running - thought should nice to have this 'pebble logs' functionality just integrated into the client - display logs on the screen - maybe with ability to share captured buffer. However Share Content Picker still expects content to be stored on the disk, so even if we capture it in memory we still need to flush it to file before sending. But yes, you may need to send it once but to see multiple times.
abranson
commented
8 years ago Dumping it all into a file before sending is ok - it's the slow trickle of log files that's not good on mobile. Managing collected logfiles for viewing, deleting and sending would be really cool. Pretty much the same way as the screenshots.
DevCon is already implementing custom log handler for STDERR. It is tee'ing STDERR to DevCon socket when SDK tool is connected. Shouldn't be a big deal to tee it to a file on request from client's Developer Tools over dbus. That file could then be sent/shared somewhere... I.e. mitigate logging issue under systemd. Also - SDK tool is enabling and printing out watches log so one can see some internals. Might be useful to enable it on-demand in rockpool and log to STDERR - to improve debugging - without need to install SDK. Thoughts?