VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git) https://git.amelek.net/vyos/vyos-1x.git/atom?h=rolling 2026-08-14T13:37:34+00:00 2026-08-14T13:37:34+00:00 Viacheslav Hletenko seversss265@gmail.com 2026-08-14T11:25:14+00:00 urn:sha1:62c6eb54233dd4d09c19b6190a50be754c9e1e4f 2026-08-13T07:04:28+00:00 Ruben Herold ruben@puettmann.net 2026-08-13T07:04:28+00:00 urn:sha1:6396d9aa43063569dfc9be2daac27f89a643252f jestabro (and dmbaturin previously, on #5362) pointed out that silently returning `default` on a non-TTY stdin still violates ask_yes_no()'s interactive-only contract, even though it stops the CPU-spin. Per T9185, sageframe's original incident confirms why: a caller that forgets an explicit non-interactive guard gets no error and no visible hang, just a process quietly pegging a core for days. Raise EOFError immediately instead, so a missing guard fails loudly and fast rather than either spinning or silently succeeding. Existing callers that are meant to run non-interactively already check no_prompt/-y before calling this (config_mgmt.py, backend.py) and are unaffected. 2026-08-09T21:06:47+00:00 Ruben Herold ruben@puettmann.net 2026-08-09T21:06:47+00:00 urn:sha1:b069ded58275ccb19d01b7dfa9944f27f0b4bb4d commit-confirm (and ~40 other call sites) hang and burn a full CPU core indefinitely when invoked with stdin that isn't a TTY, e.g. a non-interactive vbash session (vbash -c "... commit-confirm 10; exit"). input() raises EOFError immediately and repeatedly in that case, and the except handler in ask_yes_no() looped straight back to input() with no backoff or exit condition. Check stdin.isatty() up front and return the default immediately when it's not a TTY, matching what a user pressing Enter (accepting the default) would already do interactively.