New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 625027 link

Starred by 2 users

Issue metadata

Status: Verified
Merged: issue 271838
Owner: ----
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

DUT repair action should have a timeout

Project Member Reported by cywang@chromium.org, Jul 1 2016

Issue description

http://chromeos-server6.mtv.corp.google.com/results/hosts/chromeos4-row6-rack9-host8/56688435-repair/debug/autoserv.DEBUG

The time I filed bug is 6/30 8:09 pm (MTV time):
The host chromeos4-row6-rack9-host8 could not be repaired due to some servo or other issue in the lab.

However, the repair job should be aborted/failed instead of waiting forever even the original issue is removed in the lab.

====
chromeos-test@chromeos-server6:/usr/local/autotest$ ps axl | grep  56688435
0 99158  3655 31369  20   0  23736   920 pipe_w S+   pts/7      0:00 grep --color 56688435
0 99158 23584     1  30  10 188052 42912 sk_wai SNs  ?          0:08 /usr/bin/python -u /usr/local/autotest/server/autoserv -p -r /usr/local/autotest/results/hosts/chromeos4-row6-rack9-host8/56688435-repair -m chromeos4-row6-rack9-host8 -u chromeos-test -l cyan-cheets-release/R53-8464.0.0/power_build/power_StatsUSB -c --verbose --lab True -R --host-protection NO_PROTECTION --job-labels pool:suites,board:cyan-cheets,cros-version:cyan-cheets-release/R53-8464.0.0
1 99158 23658 23584  30  10 186508 35636 pipe_w SN   ?          0:00 /usr/bin/python -u /usr/local/autotest/server/autoserv -p -r /usr/local/autotest/results/hosts/chromeos4-row6-rack9-host8/56688435-repair -m chromeos4-row6-rack9-host8 -u chromeos-test -l cyan-cheets-release/R53-8464.0.0/power_build/power_StatsUSB -c --verbose --lab True -R --host-protection NO_PROTECTION --job-labels pool:suites,board:cyan-cheets,cros-version:cyan-cheets-release/R53-8464.0.0
1 99158 23665 23584  30  10 186508 35640 pipe_w SN   ?          0:00 /usr/bin/python -u /usr/local/autotest/server/autoserv -p -r /usr/local/autotest/results/hosts/chromeos4-row6-rack9-host8/56688435-repair -m chromeos4-row6-rack9-host8 -u chromeos-test -l cyan-cheets-release/R53-8464.0.0/power_build/power_StatsUSB -c --verbose --lab True -R --host-protection NO_PROTECTION --job-labels pool:suites,board:cyan-cheets,cros-version:cyan-cheets-release/R53-8464.0.0
chromeos-test@chromeos-server6:/usr/local/autotest$ date
Thu Jun 30 20:12:22 PDT 2016


 
Cc: bccheng@chromium.org
Cc: cn...@chromium.org
Mergedinto: 271838
Status: Duplicate (was: Untriaged)
Cc: semenzato@chromium.org
Owner: sbasi@chromium.org
Status: Assigned (was: Duplicate)
The problem isn't the lack of a timeout.

There's a verify and a repair job both in Queued state on
the DUT, and it's not possible to abort them.  The DUT is
refusing to be cleaned up.

Comment 6 by sbasi@chromium.org, Jul 7 2016

Cc: sbasi@chromium.org
Owner: ----
What do you mean its impossible to abort them? I just went to the UI and did...

Select Show verifies, repairs, cleanups and resets

Then select the tasks, check the box hit actions and abort.

And then a new repair job and ran and the device went back into a good state.




As for the title of this bug: having a timeout on repair would have automated what I just did.
Status: Fixed (was: Assigned)
> What do you mean its impossible to abort them? I just went to the UI and did...

When I saw the problem, I clicked several times on abort, and
they failed to abort:  The tasks remained in the Queued state.

Obviously, your karma is better than mine...

> As for the title of this bug: having a timeout on repair
> would have automated what I just did.

Well, yes, assuming whatever prevented me from aborting the
tasks didn't cause some other problem somehow.

In any event, we already have bug 271838, so I don't think we
need this bug any more.

Status: Verified (was: Fixed)
Closing. please reopen if its not fixed.

Sign in to add a comment