1462293 - Call c.Wait() after c.Execute() if command is not aborted

Status: RESOLVED INVALID

(Taskcluster :: Workers, enhancement)

Description

[Pete Moore [:pmoore][:pete]]

In bug 1458873 we learned that calling c.Wait() (for c that is a *github.com/taskcluster/generic-worker/process.Command) on an aborted command may never return. The solution was to call c.Process().Wait().

This solves the issue for when a command is aborted, but in the case it isn't, could return prematurely before logs are flushed.

The solution is to call c.Execute() followed by c.Wait() in the case of a non-aborted command, and only c.Execute() in the case of an aborted command.

Comment 1

[Pete Moore [:pmoore][:pete]]

Attachment: Github Pull Request for generic-worker

Comment 2

[Pete Moore [:pmoore][:pete]]

(In reply to Pete Moore [:pmoore][:pete] from comment #0)
> In bug 1458873 we learned that calling c.Wait() (for c that is a
> *github.com/taskcluster/generic-worker/process.Command) on an aborted
> command may never return. The solution was to call c.Process().Wait().


Correction:

*github.com/taskcluster/generic-worker/process.Command -> *os/exec.Cmd

Comment 3

[Pete Moore [:pmoore][:pete]]

So it turns out this doesn't work, because calling c.Process.Wait() twice results in the second call hanging forever.

I'm going to solve this problem a different way, by ensuring all subprocesses get killed.

This isn't trivial to implement using win32 apis but it is trivial to implement by running taskkill.exe which comes shipped with Windows.

I'll create a different bug for this.