executable resource fails because 16.04.3 includes non-existent dirs in $PATH
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Checkbox Provider - Resource |
Fix Released
|
High
|
Jeff Lane |
Bug Description
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/
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-
location: /usr/bin
name: head
location: /usr/bin
name: s390x-linux-
location: /usr/bin
name: dh_installxmlca
location: /usr/bin
find: \u2018/
find: \u2018/
find: \u2018/
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/
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/
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/
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/
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/
find: ‘/snap/bin’: No such file or directory
ubuntu@above-ox:~$ echo $?
0
ubuntu@above-ox:~$
Related branches
- Devices Certification Bot: Needs Fixing
- Maciej Kisielewski (community): Approve
-
Diff: 12 lines (+1/-0)1 file modifiedjobs/resource.pxu (+1/-0)
summary: |
- executable resource fails due to unhandled uincode characters in output + executable resource fails because 16.04.3 includes non-existent dirs in + $PATH |
description: | updated |
Changed in plainbox-provider-resource: | |
milestone: | future → 0.34.0 |
Changed in plainbox-provider-resource: | |
status: | Fix Committed → Fix Released |
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.