The beaker reboot needs to cross minute boundaries based on the method used

[trevor-vaughan]

Currently the reboot command for Unix uses who -b to detect a reboot. Unfortunately, this means that there is a race condition that may result in the system being unable to detect a successful reboot if it doesn't cross the minute boundary.

The last -F reboot command does not exist on all systems, but if it works, it can get second-level granularity. If not, we can fall back to who -b and sleep past the minute boundary before proceeding.

I'm working on a patch for this now.

[igalic]

on FreeBSD, OpenBSD, NetBSD and Solaris (Illumos) -F is not required, by which i mean, it'll probably throw an error

[trevor-vaughan]

@igalic Can you provide the output from BSD?

[igalic]

in about three hours ;)

[trevor-vaughan]

@igalic I just checked via Vagrant (because I remembered that's a thing). It won't work but it doesn't give the granularity required anyway so the fallback method will work properly.

[trevor-vaughan]

I'm reopening this issue because I just hit a weird edge case where the execution of a Beaker::Command on a remote host is returning nil.

I honestly don't see how this is possible in the code base, but it's definitely happening.

I've moved to catching all standard exceptions (yeah, I know) as the main retry block since reboots can cause really weird side effects overall.

Will upload a new patch when this is no longer occurring.

[trevor-vaughan]

The existing patch is OK for most cases but it turns out that VMs occasionally reboot and have a start time that is prior to the shutdown time.

I'm working on another update to address this (absolutely horrible) case.