Fixes danobi#40 When both the host and the VM are saturated, the VM may not be scheduled for a while, causing the connection to qga to timeout. Prior to danobi#27 the unix socket would block indefinitely. This change brings back this behaviour while we run a command, and set the timeout back to what it was before running the command. This way, we can give a chance to the host/vm to recover. Tested by running: ``` stress --cpu 256 --io 256 --vm 4 --vm-bytes 1024M --timeout 1000s ``` in the host, and ``` stress --cpu 512 --io 512 --vm 4 --vm-bytes 1024M --timeout 100s & while true; do date; sleep 2; done ``` in the guest. Output showsa that the VM was struggling to run its loop and print the date until the stress tool was done: ``` ===> Setting up VM [ 1.840931] 9pnet: Limiting 'msize' to 512000 as this is the maximum supported by transport virtio ===> Running command Thu Jan 25 01:43:12 PM PST 2024 stress: info: [85] dispatching hogs: 512 cpu, 512 io, 4 vm, 0 hdd [ 5.493242] hrtimer: interrupt took 3387058 ns [ 89.331664] clocksource: timekeeping watchdog on CPU1: hpet wd-wd read-back delay of 31697570ns [ 89.465647] clocksource: wd-tsc-wd read-back delay of 2998850ns, clock-skew test skipped! Thu Jan 25 01:45:00 PM PST 2024 Thu Jan 25 01:45:09 PM PST 2024 Thu Jan 25 01:45:12 PM PST 2024 stress: info: [85] successful run completed in 124s Thu Jan 25 01:45:17 PM PST 2024 Thu Jan 25 01:45:19 PM PST 2024 Thu Jan 25 01:45:21 PM PST 2024 Thu Jan 25 01:45:23 PM PST 2024 Thu Jan 25 01:45:26 PM PST 2024 Thu Jan 25 01:45:28 PM PST 2024 ``` Signed-off-by: Manu Bretelle <chantr4@gmail.com>

Commits

Commits on Jan 25, 2024

run_command: wait for command to run indefinitely