Support logging of serial traffic in the exporter#1862
Conversation
49eb27c to
0e1c1f0
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1862 +/- ##
========================================
+ Coverage 46.0% 47.5% +1.5%
========================================
Files 180 180
Lines 14439 14459 +20
========================================
+ Hits 6654 6882 +228
+ Misses 7785 7577 -208
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
I like the general idea, especially since we can make use of the existing ser2net configuration capabilities for that. The thing I worry about is how to make this accessible to users and how to handle log rotation and time stamping so users are able to correlate which part of the log file was generated by them. Or do you intend this to be a purely administrative aid in debugging failing lab hardware? Edit: I haven't checked that time stamping is handled by ser2net, if you could add a sample log file that would be great. For the user side we already have |
The exporter currently cannot tell which user acquired a place - only which client did, via the host/user pair stored as 'acquired'. This blocks features that want to attribute resource use to a specific user, such as per-user serial trace files or audit logs on the exporter host. Extend ExporterSetAcquiredRequest with a 'user' field containing the host/user identity that acquired the place. The field is populated from place.acquired which already holds host/user. The exporter stashes the value on the ResourceExport so subclasses can use it (e.g. SerialPortExport for per-user trace files). Older coordinators that don't send the field continue to work as before; the field defaults to None on the exporter side. Signed-off-by: Simon Glass <sjg@chromium.org>
Lab admins running shared boards have no independent record of what is happening on the serial console. The per-client --logfile option captures output for the user who set it, but the lab owner has no way to see traffic across all sessions, which hampers post-mortem when a board ends up in a bad state and the question is which commands got it there. Add support for centralised serial-traffic logging on the exporter host. When LG_SERIAL_TRACE_DIR is set, the exporter passes ser2net's trace-both option for each acquire, capturing every byte that flows in either direction to a per-board, per-user file under that directory. ser2net is started fresh on each resource acquire and stopped on release, so each instance can include both the board (group name) and the acquiring user in the filename: <board>-<user>.log (e.g. bbb-okaro_sjg.log). Repeated acquires by the same user on the same board append to the same file. The user identity comes from the coordinator via the new 'user' field in ExporterSetAcquiredRequest (added in a previous commit). The group name is plumbed from the resource config through add_resource() into the ResourceExport so the trace path can use the human-readable board name instead of the device path. trace-both-timestamp is also enabled, so ser2net writes timestamped OPEN and CLOSE markers around each session. The console data itself is recorded verbatim with both directions interleaved, and the session markers give the lab admin the boundaries needed to correlate a trace with other audit logs. Admins who need per-line timestamps at the cost of readability can additionally set LG_SERIAL_TRACE_HEXDUMP=1 to switch ser2net into hex+ASCII mode, where every line is timestamped. Series-changes: 2 - Mention --lg-log and ConsoleLoggingReporter alongside --logfile, and clarify that the exporter trace is the operator's independent record (the user cannot influence it) - Add real default-mode and hex-mode trace snippets to doc/usage.rst, captured from a running kea exporter - Add LG_SERIAL_TRACE_HEXDUMP=1 to opt into ser2net's hexdump mode (timestamp on every line, at the cost of readability); cover both code paths with tests - Correct the description: in the default mode only the OPEN and CLOSE session markers are timestamped, not every line - Document filename fallbacks: device basename for missing group_name, literal 'unknown' for missing user - Add doc sub-sections for systemd setup, file permissions, privacy implications and disk-usage growth in hexdump mode - Note that log rotation is left to logrotate on the admin host, and that ser2net's append-on-open behaviour makes copytruncate/daily safe Signed-off-by: Simon Glass <sjg@chromium.org> Co-developed-by: Claude Opus 4.6 <noreply@anthropic.com>
Thanks for the review! To clarify the intent: this is an admin-only audit/debug aid, not a user-facing logging mechanism. It complements rather than replaces
The new exporter trace is specifically for "which user ran which commands on board X between Tue 14:00 and 17:00 to put it in this state"-type questions, which the per-client logs don't answer. On timestamps, the exporter does pass (Both directions land in the same byte stream, which is why each typed character shows up twice - once from the user, once from the board's local echo.) If per-line timestamps actually matter for a deployment, v2 adds On log rotation: not handled in the exporter itself. ser2net opens the trace file in append mode on each acquire, so I updated usage.rst to show examples and talk about log rotation. |
Description
Add optional centralised serial-traffic logging on the exporter
host: when
LG_SERIAL_TRACE_DIRis set, the exporter passestrace-bothto the per-acquireser2netand the resulting logfiles are named
<board>-<user>.log. This closes a visibilitygap for shared/multi-user labs where the per-client
--logfileonly captures one user's session and the operator otherwise has
no independent record of what is happening on the console.
Three commits:
userfield toExporterSetAcquiredRequestso the exporter knows who acquired a place; needed by (2).
Older coordinators that don't send the field continue to work.
usage section in
doc/usage.rst, an env-var entry in theexporter man page (regenerated under
man/).labgrid/remote/generated/*from coverage soprotoc regen noise stops dragging the patch-coverage threshold
under on routine protocol changes.
Tested on my own lab (~50 boards exported via ser2net 4.x,
including BeagleBone Black, Raspberry Pi 3, Coral and a handful
of x86 systems) over tailscale. Trace files correctly capture
every keystroke and reply for each acquire session, and append
on repeated acquires by the same user on the same board.
Checklist