Re: [chromium-dev] Browser tests and the Windows Task Scheduler

[Paweł Hajdan, Jr.]

[bcc:chromium-dev, +infra-dev]

On Wed, Dec 9, 2015 at 5:25 PM, Raphael Kubo da Costa <raphael.ku...@intel.com> wrote:

Hi there,

I'm trying to set up some downstream Buildbot slaves, but Windows is
causing me some headaches (I'm dealing with Windows 8.x/Server 2012
here).

So far, my plan was to use the Windows Task Scheduler to run a .bat file
that launches the Buildbot slave that builds Chromium and runs some
tests.

However, by default (i.e. if I configure the task to run only when the
slave user is logged in) all processes are children of the Task
Scheduler, which launches them inside a job object that seems to be
fairly restrictive: CreateProcess() in base/process/launch_win.cc fails
with Access Denied when it sets the CREATE_BREAKAWAY_FROM_JOB flag, and
thus things like content_browsertests cannot launch any test.

If I instead create a task and set it to run regardless of whether the
slave user is logged in or not (and provide the user's password as part
of the process), the restrictive Task Scheduler job object does not seem
to be used, but the task will be run from Session 0 (which is
non-interactive) and all tests just time out.

Are the Chromium Windows slaves set up differently? Has anyone tried
setting up something similar?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Marc-Antoine Ruel]

Most tests expect to be running in a normal user context, not a service context. IIRC, the service handler creates the process within a job object. Since Chrome uses job object extensively, this doesn't work well.

The workaround used is to setup the bot to "auto login" and use "Start Menu\Programs\Startup" to start the bot. This is the only way to run interactive_ui_tests successfully.

M-A

 

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAATLsPZi8fNnJW0HW2UkuW%2BNF0z%3DOqnwiWTiAyd%2B%3DQeUj_%3Dpkw%40mail.gmail.com.

[Raphael Kubo da Costa]

Marc-Antoine Ruel <mar...@chromium.org> writes:

> Most tests expect to be running in a normal user context, not a service
> context. IIRC, the service handler creates the process within a job object.
> Since Chrome uses job object extensively, this doesn't work well.
>
> The workaround used is to setup the bot to "auto login" and use "Start
> Menu\Programs\Startup" to start the bot. This is the only way to run
> interactive_ui_tests successfully.

Sorry, I only managed to get back to this a few days ago.

By service context, I'm assuming you mean session 0. That's the case I
mentioned in the end of my original message, when I said all tests time
out when it's used. However, session 0 is only used if I don't configure
the task to "only run when the user is logged in". If I do, the task is
run from the user context, and that's what I'm using.

I think the problem actually comes from this excerpt in
base/process/launch_win.cc that was added in ~2010:

if (options.job_handle) {
[...]
// If this code is run under a debugger, the launched process is
// automatically associated with a job object created by the debugger.
// The CREATE_BREAKAWAY_FROM_JOB flag is used to prevent this.
flags |= CREATE_BREAKAWAY_FROM_JOB;
}

Other bits that also set this flag
(sandbox/win/{tools/launcher/launcher.cc,src/target_process.cc}, for
example) already do that only if we're on older Windows releases, and
doing the same allows me to run content_browsertests and
interactive_ui_tests from the Task Scheduler.

I'll send a CL for review to get others to take a look at this as well.
The Windows user still needs to be set up to "auto login", but the other
half of the problem is solved.

[Raphael Kubo da Costa]

Raphael Kubo da Costa <raphael.ku...@intel.com> writes:

> I'll send a CL for review to get others to take a look at this as well.
> The Windows user still needs to be set up to "auto login", but the other
> half of the problem is solved.

For posterity: https://codereview.chromium.org/1546313002 (which landed
a few days ago).