spec: change executable path in App.Exec to be PATH-dependent.

[yifan-gu]

The searching of the executable path duplicates the shell. Copied from
the description in man exec(3).

[yifan-gu]

cc @philips @jonboulle @vbatts @vcaputo

[jonboulle]

Cc @thockin, curious on his take
On Oct 9, 2015 13:47, "Yifan Gu" notifications@github.com wrote:

cc @philips https://github.com/philips @jonboulle
https://github.com/jonboulle @vbatts https://github.com/vbatts
@vcaputo https://github.com/vcaputo

—
Reply to this email directly or view it on GitHub
#527 (comment).

[yifan-gu]

ping?

[vcaputo]

@yifan-gu What is the motivation for supporting this?

[yifan-gu]

@vcaputo Mostly because k8s's pod spec allows relative path.

[thockin]

We do? Where do you see that?

On Thu, Oct 15, 2015 at 4:35 PM, Yifan Gu notifications@github.com wrote:

@vcaputo https://github.com/vcaputo Mostly because k8s's pod spec
allows relative path.

—
Reply to this email directly or view it on GitHub
#527 (comment).

[yifan-gu]

It's not explicitly said that relative path is allowed or not in the spec But I can set something like sh in Container.Command[]. For example in some e2e tests

[yifan-gu]

@thockin ^

[thockin]

There's a difference between being a relative name and being a PATH-dependent name. Docker does support PATH lookups on its exec. Does rkt?

[vcaputo]

At this time rkt largely reflects the ExecStart rules of systemd as documented in systemd.service(5), so it's an absolute path only.

[yifan-gu]

@vcaputo @thockin Actually the systemd will invoke diagexec to wrap the app. and diagexec handles PATH lookup correctly

[thockin]

So other than the title of this PR, the change itself seems to bring the in line with Docker's behavior and kubernetes' expectations. LGTM

[yifan-gu]

Thanks, title changed.

[vcaputo]

@yifan-gu I know diagexec supports it, that was done for the sake of rkt enter so users could have PATH lookups succeed in ad-hoc cli invocations. But the current rkt implementation (without your changes) prevent non-absolute paths, and it's worth noting there's already been at least one attempt to remove diagexec in favor of systemd executing the app directly, some food for thought.