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

Issue 688226 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 5
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

"repo upload --cbr ." from autotest dir enters chroot and takes minutes to run

Project Member Reported by derat@chromium.org, Feb 3 2017

Issue description

My "repo upload --cbr ." command, executed in src/third_party/autotest/files outside of my chroot, is taking a really long time and not displaying any output. It prompted me for my password for sudo when I first ran it, which seemed weird (but now I see it probably wanted that to enter the chroot).

"top" shows a python2 process taking up 100% CPU, and ps shows a bunch of processes like this:

root     11380 17.0  0.0 120260 45012 pts/33   S+   19:36   0:00 python2 /derat/chromeos/chromite/bin/cros_sdk -- equery -qC uses chromeos-base/autotest-tests-wimax chromeos-base/autotest-server-tests-shill chromeos-base/autotest-tests chromeos-base/autotest-tests-security chromeos-base/autotest-tests-cros-disks chromeos-base/autotest-tests-cloud-services chromeos-base/autotest-tests-cellular chromeos-base/autotest-tests-arc-public chromeos-base/autotest-server-tests-telemetry chromeos-base/autotest-tests-p2p chromeos-base/autotest-tests-touchpad chromeos-base/autotest-deps-cellular chromeos-base/autotest-deps-graphics chromeos-base/autotest-tests-power chromeos-base/autotest-server chromeos-base/autotest-tests-ownershipapi chromeos-base/autotest-deps-glmark2 chromeos-base/autotest-tests-wifi-bootstrapping chromeos-base/autotest-private-board chromeos-base/autotest-tests-shill chromeos-base/autotest-chrome chromeos-base/autotest-server-deps chromeos-base/autotest-web-frontend chromeos-base/autotest-deps-webgl-clear chromeos-base/autotest-tests-ltp chromeos-base/autotest-deps-piglit chromeos-base/autotest-deps-webgl-mpd chromeos-base/autotest-private-all chromeos-base/autotest-deps chromeos-base/autotest-deps-webgl-perf chromeos-base/autotest-all chromeos-base/autotest-tests-audio chromeos-base/autotest-deps-ltp chromeos-base/autotest-server-tests-bluetooth chromeos-base/autotest-tests-cryptohome chromeos-base/autotest-deps-p2p chromeos-base/autotest-deps-glbench chromeos-base/autotest-fakemodem-conf chromeos-base/autotest-tests-debugd chromeos-base/autotest-tests-graphics chromeos-base/autotest-deps-touchpad chromeos-base/autotest-server-tests chromeos-base/autotest-tests-peerd chromeos-base/autotest-client chromeos-base/autotest-deps-uiautomator chromeos-base/autotest-tests-tpm

It eventually completed minutes later and printed a presubmit error about an empty "BUG=" line, which was anticlimactic.

Running it a second and third time is taking just long. Any guesses about what it's doing and how I can make it stop?
 
pretty sure this is WAI.  see  issue 273133  &  issue 365615 .

as for why it's so abysmally slow, i suspect part of the reason is  issue 659864 .

Comment 2 by derat@chromium.org, Feb 9 2017

Cc: jrbarnette@chromium.org posciak@chromium.org
Thanks! Cc-ing people from a few of the closed bugs.

I suspect it may be possible to do a much-faster, good-enough check that doesn't run potentially-very-slow equery commands within the chroot. Would you object to me making site_utils/presubmit_hooks/check_control_files.py just check that the test name appears in one of the autotest ebuild files instead? It could maybe even source the ebuilds and look at $USE, if you think that's necessary.
Components: -Infra>Git Infra>Client>ChromeOS>Test
Status: WontFix (was: Untriaged)
i don't think we're going to do any work on this, and the blocking bugs are resolved now.  it'll also be a bit moot with conversion to tast.

Sign in to add a comment