executable resource fails because 16.04.3 includes non-existent dirs in $PATH

[Jeff Lane ]

Note, the unicode chars are a red herring... still a problem, but not this problem. The real issue is that 16.04.3 adds some non-existent dirs to $PATH on MAAS installs (haven't tested it with ISOs), and that causes the executable resource job to fail. It's not catastrophic, but then again, because of a different bug, that failed resource job now appears in the list of failed test cases at the end of a run, and testers are commenting/complaining about failing the "Executable Test".

when the command for executable is run within the subshell created by checkbox-cli, for some reason the find command is encountering some strange unicode characters (single quotes) that are causing it to fail:

name: canonical-certification-precheck
location: /usr/bin

name: head
location: /usr/bin

name: s390x-linux-gnu-objcopy
location: /usr/bin

name: dh_installxmlcatalogs
location: /usr/bin
find: \u2018/home/ubuntu/bin\u2019: No such file or directory
find: \u2018/home/ubuntu/.local/bin\u2019: No such file or directory
find: \u2018/snap/bin\u2019: No such file or directory

name: pygettext2.7
location: /usr/bin

The job is pretty simple

find -H $(echo "$PATH" | sed -e 's/:/ /g') -maxdepth 1 -type f -executable -printf "name: %f\nlocation: %h\n\n"

what's curious is where those single quote chars are coming from.

It appears that some deployments of 16.04.3 are being set with the POSIX fallback locale and I think that's the issue:

From a s390x instance:
ubuntu@s1lp9g003:~$ echo $LANG
C
ubuntu@s1lp9g003:~$ find -H $(echo "$PATH" | sed -e 's/:/ /g') -maxdepth 1 -type f -executable -printf "name: %f\nlocation: %h\n\n"
find: '/home/ubuntu/bin': No such file or directory
find: '/home/ubuntu/.local/bin': No such file or directory
name: invoke-rc.d
location: /usr/sbin

<snip>

name: dd
location: /bin

find: '/snap/bin': No such file or directory
ubuntu@s1lp9g003:~$

ubuntu@s1lp9g003:~$ echo $PATH
/home/ubuntu/bin:/home/ubuntu/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

So it's maybe not a matter of locale, but the fact that the deployment is inserting things into $PATH that don't exist.

This is from a fresh install of 16.04.3 on an amd64 box:

ubuntu@above-ox:~$ echo $PATH
/home/ubuntu/bin:/home/ubuntu/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

ubuntu@above-ox:~$ find -H $(echo "$PATH" | sed -e 's/:/ /g') -maxdepth 1 -type f -executable -printf "name: %f\nlocation: %h\n\n" 1>/dev/null
find: ‘/home/ubuntu/bin’: No such file or directory
find: ‘/home/ubuntu/.local/bin’: No such file or directory
find: ‘/snap/bin’: No such file or directory

So the resource job needs to be able to cope with these without failing. Given taht this is just an enumerator, perhaps the best option is to just do something like this with the command:

ubuntu@above-ox:~$ find -H $(echo "$PATH" | sed -e 's/:/ /g') -maxdepth 1 -type f -executable -printf "name: %f\nlocation: %h\n\n"; true

ubuntu@above-ox:~$ find -H $(echo "$PATH" | sed -e 's/:/ /g') -maxdepth 1 -type f -executable -printf "name: %f\nlocation: %h\n\n" 1>/dev/null; true
find: ‘/home/ubuntu/bin’: No such file or directory
find: ‘/home/ubuntu/.local/bin’: No such file or directory
find: ‘/snap/bin’: No such file or directory
ubuntu@above-ox:~$ echo $?
0
ubuntu@above-ox:~$

[Jeff Lane  (bladernr)]

Note, after some investigation, it seems that the inclusion of these non-existent bits in $PATH is intentional, so this is definitely a necessary workaround.