What do you suggest should happen?

I'm very sorry for the long delay. I missed the notification.
I would expect the error from Run() to match ctx.Err(), given that it's the actual cause of the command being aborted.
In case it helps, I'm using the following workaround:

	// return errors.Trace(cmd.Run())
	if err := cmd.Run(); err != nil {
		if ctx.Err() != nil {
			return errors.Annotate(err, ctx.Err().Error())
		}
		return errors.Trace(err)
	}

BTW thanks for adding this to the 1.10 milestone! :)

I guess it makes sense that cmd.Run returns an exec.ExitError when a process has been actually created; otherwise one couldn't access e.g. os.ProcessState which might make sense even if the process has been killed because the context deadlined.

What if we the ExitError's Error() method was able to access the context error and render e.g.:

context deadline exceeded, signal: killed

This gets at a more general problem of chaining errors: ideally, I agree with @mmikulicic that Run should return an ExitError that shows both the immediate cause (the signal) and the secondary one (the cancellation).

It would be nice if we had some standard means to express that.
(CC: @dsnet, @rogpeppe, @davecheney, @crawshaw)

Also note that if you cancel a context.Context in general, you have no guarantee that the function you passed it to actually returns ctx.Err() even when you are only making calls within the same (Go) process. The convention of returning ctx.Err() is nice to follow, but not universally enforced.

In general, if you cancel a Context you should ignore whatever error is returned by the call you passed it to. (As a corollary, if you return an error you should not also log it: it is up to the caller to determine whether it is still relevant.)

Does this mean it's up to the caller to do something with it, e.g.:

func Foo() error {
    if err := exec.CommandContext(ctx, "sleep", "5").Run(); err != nil {
        if err := ctx.Err(); err != nil {
            return err
        }
        return err
    }
}

or:

import "github.com/juju/errors"

func Foo() error {
    if err := exec.CommandContext(ctx, "sleep", "5").Run(); err != nil {
        if ctx.Err() != nil {
            err = errors.Wrap(err, ctx.Err())
        }
        return err
    }
}

or some custom (or yet to be defined) helper:

func Foo() error {
    if err := exec.CommandContext(ctx, "sleep", "5").Run(); err != nil {
        return WrapContextError(ctx, err) // passes err through when ctx is not cancelled
    }
}

?

Does this mean it's up to the caller to do something with it, e.g.:

None of the callers you're describing there have a Context parameter. I would expect to see something more like:

func Foo(ctx context.Context) (Bar, error) {
	out, err := exec.CommandContext(ctx, …).Output()
	if err != nil {
		return Bar{}, err
	}
	return parseBar(out)
}

…

func SomeOtherFunction(ctx context.Context) error {
	ctx, cancel := context.WithTimeout(ctx, veryLongWatchdogTimeout)
	defer cancel()
	bar, err := Foo(ctx)
	if err != nil {
		if ctx.Err() == context.DeadlineExceeded {
			return watchdogError(err)
		}
		return internalError(err)
	}
	return doSomethingWith(bar)
}

Honestly, though, I don't really understand most uses of context.WithTimeout to begin with. With explicit cancellation, it's much easier to know whether you intentionally canceled the operation (and thus whether you should ignore the details of the error).

yeah I forgot declaring the signature in the Foo function

Honestly, though, I don't really understand most uses of context.WithTimeout to begin with. [...]

are you suggesting that it's better to explicitly set up a timer that calls cancel instead of having this functionality built in the context library?

are you suggesting that it's better to explicitly set up a timer that calls cancel instead of having this functionality built in the context library?

No, I'm suggesting that most callers should propagate cancellation (e.g. from an incoming http.Request, or from a signal as described in #21521) instead of applying arbitrary timeouts.

ah, well, the parent timeout is preserved, I guess this is just about whether or not it makes sense to allow a call to further narrow down the timeout; we're getting off topic :-)

How's it going here @aruiz14 @mmikulicic @bcmills? Just a gentle ping.

I agree it makes sense to return an error that indicates the process was terminated when a process is spawned but killed, rather than returning a context.DeadlineExceeded (even if that was the reason for termination).
However, I do think it is good to reflect this behaviour in the docs (or at least in the example for CommandContext). Possibly hint that callers may inspect context.Err() themselves to find whether the deadline has exceeded. What do you all think?

A vaguely related incosistency I'd like to point out: Cmd.Wait() returns an errorString, but Cmd.Run() returns ExitError. I feel it makes sense to return an ExitError from both methods.