The reset tasks are failing with this symptom:
	FAIL	----	verify.cros	timestamp=1505749813	localtime=Sep 18 08:50:13	command execution error
  * Command: 
      /usr/bin/ssh -a -x    -o ControlPath=/tmp/_autotmp_Jua8h9ssh-
      master/socket -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
      -o BatchMode=yes -o ConnectTimeout=30 -o ServerAliveInterval=900 -o
      ServerAliveCountMax=3 -o ConnectionAttempts=4 -o Protocol=2 -l root -p 22
      chromeos6-row2-rack20-host7 "export LIBC_FATAL_STDERR_=1; if type
      \"logger\" > /dev/null 2>&1; then logger -tag \"autotest\"
      \"server[stack::upstart_status|run|wrapper] -> ssh_run(status system-
      services | grep start/running)\";fi; status system-services | grep
      start/running"
  Exit status: 1
  Duration: 0.0360298156738

Repair finds nothing wrong with the DUT, but it does report this:
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/supplied_sslh_fork.20170918.084919.2318.log
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084959.2271.core
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084959.2271.meta
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/service_failure.20170918.085047.0.meta
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/supplied_sslh_fork.20170918.084919.2318.core
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084959.2266.meta
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084959.2271.dmp
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084918.4275.meta
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084918.4281.meta
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084918.4275.dmp
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/os-release
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084918.4275.core
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084959.2266.core
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084918.4281.dmp
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/lsb-release
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084918.4281.core
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/service_failure.20170918.085047.0.log
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/run_oci.20170918.084959.2266.dmp
	INFO	----	Orphaned Crash Dump	timestamp=1505750027	localtime=Sep 18 08:53:47	/var/spool/crash/supplied_sslh_fork.20170918.084919.2318.meta


The reason for the reset failure is outlined in crbug.com/765686#c9; the
DUT is caught in a temporary state that causes a mis-diagnosis of "Chrome
failed to start".  Here's why the loop:
  * The failure first happens at provision:  after reboot, system-services
    hasn't finished starting, so verify fails.
  * The failed provision triggers repair.  At that point, system-services
    is running by the time repair makes its check, so repair finds nothing
    wrong.  But... the last thing repair does is reboot, which puts us back
    into the temporary starting state just in time for the next reset.

As for _why_ this temporary state is lasting long enough to show up so
significantly, that's probably because whatever is causing the crashes
cited above is also holding up 'system-services'.

The principle problem here is the crashes:  Whatever is causing the
crash dumps is a bug that needs fixing.

Secondarily, there's an argument that the verification check is too
stringent.  Mostly, I think that's right, but there's a critical
trade-off to consider:  Almost any fix to make the check more
forgiving would paper over a problem like the crashes above.  I'd
be really concerned that papering over those failures would make the
cure worse than the disease.

> This took down a cq build: https://luci-milo.appspot.com/buildbot/chromeos/wizpig-paladin/935#

Ah, something else:  This bug and bug 765686 seem to be isolated
to the paladins.  There's a good chance that the root cause here
is a bad CL.  We should have enough failed runs at this point to
pinpoint that bad CL.

+sheriff

+secondary sheriff

In https://uberchromegw.corp.google.com/i/chromeos/builders/wizpig-release?numbuilds=200

It seems that it fails pretty often.

I tried to look at the diffs between build #1507..#1506, or #1491..#1490 but nothing looks related:
https://crosland.corp.google.com/log/9946.0.0..9947.0.0
https://crosland.corp.google.com/log/9930.0.0..9931.0.0

> In https://uberchromegw.corp.google.com/i/chromeos/builders/wizpig-release?numbuilds=200
>
> It seems that it fails pretty often.

Yeah, the wizpig-release builder is pretty unhealthy, and looking
at some of the provision failures, they do show the "system-services"
failure mentioned here.  However, they _don't_ show the extra crash
dumps, nor are there any DUTs stuck in a reset/repair cycle as cited
above.

So...  The tree is broken for wizpig, but it seems at least one recent
wizpig-paladin run had a bad CL that made things worse.

I replaced the ethernet cable for this DUT and restored network connectivity.

sounds fixed