This does not appear to be a specific test failure as it occurs across a range of tests:
graphics_Gbm
graphics_Idle.arc
cheets_PlayStoreTest
graphics_Drm.bvt
cheets_NotificationTest
cheets_KeyboardTest

It also occurs across a range of devices. Counts from the last half dozen failures:

11 chromeos6-row2-rack23-host11/
10 chromeos6-row2-rack23-host6/
5 chromeos6-row2-rack23-host9/
1 chromeos6-row2-rack23-host13/
3 chromeos6-row2-rack23-host15/
1 chromeos6-row2-rack23-host17/

Looking at the suite details I don't see any obvious pattern, e.g.
https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/suiteDetails?suiteId=175110757

The failing code (which appears to be the same for all test failures) is called from here:

def find_connected_inputs(self):
        """Determine the nodes of all present input devices, if any.
        Cycle through all possible /dev/input/event* and find which ones
        are touchpads, touchscreens, mice, keyboards, etc.
        These nodes can be used for playback later.
        If the type of input is already emulated, prefer that device. Otherwise,
        prefer the last node found of that type (e.g. for multiple touchpads).
        Record the found devices in self.devices.

It looks like it relies on a timeout waiting for a tmp file to be written.

My guess is that a recent change is causing that to take longer or fail more frequently before. We should look for the first occurence and see if we can identify any suspicious changes.

The first PFQ failure with this was @ R66-10363.0.0-b897, chrome @ 533716
https://uberchromegw.corp.google.com/i/chromeos.chrome/builders/caroline-tot-chrome-pfq-informational/builds/897

The first paladin failure wash @R66-10365.0.0-rc1, chrome 66.0.3329.0
https://luci-milo.appspot.com/buildbot/chromeos/caroline-paladin/2541

Given that this is flaky the correlation is pretty close, but it may have been introduce earlier than R66-10363.0.0-b897, making this challenging to track down.

That said, Chrome 66.0.3329.0 first made it through the PFQ @R66-10334.0.0, a week prior to when we started seeing these failures, so we can probably assume this was not a chrome issue.

+CrOS sheriffs

Does anyone know a straightforward way to get the CrOS changes leading up to R66-10363.0.0-b897 ?

+cywang@, +kathrelkeld@ for most recent-ish changes to client/cros/input_playback. Any idea what is actually failing here?

 Issue 809151  has been merged into this issue.

Link to failing autotest code:
https://cs.corp.google.com/chromeos_internal/src/third_party/autotest/files/client/cros/input_playback/input_playback.py?q=_find_device_properties&l=180

The failing part is when we're waiting for evtest to output info for a single input.  I'll dig into this one.

Thanks! At minimum it would be great to progagate up a better error than "unnamed condition" :)

On one of the failing machines, I found something odd: /dev/input/event4 exists but returns "Invalid argument" when passed to evtest.  This doesn't happen on other Caroline machines - and not all the time on this one machine.  Not sure why that is, but I've put up a CL to ignore this case.

https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/907949

Triage nag: This Chrome OS bug has an owner but no component. Please add a component so that this can be tracked by the relevant team.

<UI triage> Bug owners, please add the appropriate component to your bug. Thanks!