THREESCALE-7942: Apicast logs shows permission denied in a tmp file

[ernaniaz]

This commit removes the warning message at the start of APIcast POD
like this one:
env: '/tmp/FXal6CekIq': Permission denied

The message occur at the start of OpenResty script, that check their own
script, but there's no execution permission to do that, showing this
warning message.

To not change the behavior of the script, this patch just added a
"2>/dev/null" at the end of the command, so, if it works, will not
change what's expected.

If changed the file mode to 0755, another error will be shown. This
indicates that this command was coded for a specific function not used
here.

This commit fix the Jira issue THREESCALE-7942.

https://issues.redhat.com/browse/THREESCALE-7942

[kevprice83]

This looks like we are just hiding the problem by not printing it to the error log stream. If in a subsequent release this does actually cause a problem then it will be even harder to debug.

I would suggest that we look at the Dockerfile or s2i which builds the image. Is this reproducible on an upstream image in quay.io? If yes then maybe the upstream and downstream images are built the same way and we can address this directly in the upstream.

If this issue is only reproducible in the downstream then we might need help accessing that environment to modify the artifacts where the local user permissions are set when building the container image.

Possibly diong something like:

chown -R 1001:0 /tmp

Will be enough.

[ernaniaz]

Doing a chown -R 1001:0 /tmp will not fix. Please refer to my comment in the Jira Issue. The error happen because it's not an executable (+x) file, and not because of ownership or directory permission. If you fix the permission of the file, which is 600 by default to 700, it will throw a longer error, and will not return anything useful to the code. This is clearly a code that it's not used in the APIcast POD initialization. We could remove this code, but I suggested to suppress the error message in case some day it became useful.

[eguzki]

I agree with Kevin. stderr should not be shadowed.

s2i is gone, so we would need to fix the docker file (or whatever is being built from the docker build process). It is also happening in upstream, so I suggest we first fix it in upstream and then port the fix to downstream.

I can help with that

[eguzki]

@ernaniaz I am trying to address this issue in #1398

I would appreciate your feedback

[eguzki]

closing as this issue was covered in #1398