-
Notifications
You must be signed in to change notification settings - Fork 207
Description
faux-mgs
allows us to attach to a gimlet's serial console via the SP. While faux-mgs
is running, it ensures it's regularly sending serial console-related packets (either writes if there's data, or keeepalives if there isn't). On a clean exit, faux-mgs will detach itself from the console. But on a non-clean exit, the SP is responsible for eventually timing out the connection and allowing new attach requests. However, it looks like only check for staleness at
hubris/task/control-plane-agent/src/mgs_gimlet.rs
Lines 282 to 303 in 1d3f3d5
// Do we have an attached MGS instance that hasn't gone stale? | |
let (mgs_addr, sp_port) = match &self.attached_serial_console_mgs { | |
Some(attached) => { | |
// Check whether we think this client has disappeared | |
let client_age_ms = sys_get_timer() | |
.now | |
.saturating_sub(attached.last_keepalive_received); | |
if Duration::from_millis(client_age_ms) | |
> SERIAL_CONSOLE_IDLE_TIMEOUT | |
{ | |
self.usart.clear_rx_data(); | |
self.attached_serial_console_mgs = None; | |
return None; | |
} | |
(attached.address, attached.port) | |
} | |
None => { | |
// Discard any buffered data and reset any usart-related timers. | |
self.usart.clear_rx_data(); | |
return None; | |
} | |
}; |
This is inside the code path for "the SP has serial console data to send to faux-mgs". If the console is idle (e.g., someone left it sitting at a shell prompt), the SP will never send data, so will never realize the faux-mgs client has gone away. This isn't a major problem, because faux-mgs can forcibly detach any previous session, but it is annoying because it makes it look like there might be someone else on the console when there isn't. A pretty easy fix would be to also check for staleness in serial_console_attach()
.