[LU-13960] conf-sanity test 53a and 53b fail with ‘/usr/lib64/lustre/tests/functions.sh: line 152: var: invalid indirect expansion’ Created: 12/Sep/20 Updated: 23/Dec/20 Resolved: 19/Sep/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.14.0, Lustre 2.12.6 |
| Fix Version/s: | Lustre 2.14.0, Lustre 2.12.6 |
| Type: | Bug | Priority: | Minor |
| Reporter: | James Nunez (Inactive) | Assignee: | James Nunez (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | ubuntu20 | ||
| Environment: |
Ubuntu 20.04 clients |
||
| Severity: | 3 |
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
conf-sanity test_53a and test_53b both fail with error message 'test_53* returned 1'. We’ve only seen this error for Ubuntu 20.04 testing at https://testing.whamcloud.com/test_sets/9fd59f4e-1340-4bc2-8a5f-0c8edb768df2 . If you look at the client logs, you will see the error == conf-sanity test 53a: check OSS thread count params =============================================== 11:15:05 (1599736505) start mds service on trevis-210vm8 … trevis-210vm8: trevis-210vm8.trevis.whamcloud.com: executing udevadm trigger modules unloaded. /usr/lib64/lustre/tests/functions.sh: line 152: var: invalid indirect expansion test_53a returned 1 FAIL 53a (76s) and == conf-sanity test 53b: check MDS thread count params =============================================== 11:16:21 (1599736581) … trevis-210vm8: trevis-210vm8.trevis.whamcloud.com: executing udevadm trigger modules unloaded. /usr/lib64/lustre/tests/functions.sh: line 152: var: invalid indirect expansion test_53b returned 1 FAIL 53b (99s) Looking at conf-sanity tests 53a and 53b, we can see that they both call thread_sanity() that calls setmodopts(). Looking at setmodopts() in functions.sh, we see on line 152 that the variable ‘_var’ used in the function earlier is used at ‘${!var}’
128 setmodopts() {
129 local _append=false
130
131 if [ "$1" = -a ]; then
132 _append=true
133 shift
134 fi
135
136 local _var=MODOPTS_$1
137 local _newvalue=$2
138 local _savevar=$3
139 local _oldvalue
140
141 # Dynamic naming of variables is a pain in bash. In ksh93 we could
142 # write "nameref opts_var=${modname}_MODOPTS" then assign directly
143 # to opts_var. Associative arrays would also help, alternatively.
144 # Alas, we're stuck with eval until all distros move to a more recent
145 # version of bash. Fortunately we don't need to eval unset and export.
146
147 if [ -z "$_newvalue" ]; then
148 unset $_var
149 return 0
150 fi
151
152 _oldvalue=${!var}
153 $_append && _newvalue="$_oldvalue $_newvalue"
Could the missing “_” in front of ‘var’ be causing this issue? I’ll submit a patch to test this out. |
| Comments |
| Comment by Gerrit Updater [ 12/Sep/20 ] |
|
James Nunez (jnunez@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/39891 |
| Comment by Gerrit Updater [ 19/Sep/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/39891/ |
| Comment by Peter Jones [ 19/Sep/20 ] |
|
Landed for 2.14 |
| Comment by Gerrit Updater [ 21/Sep/20 ] |
|
James Nunez (jnunez@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/39985 |
| Comment by Gerrit Updater [ 22/Oct/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/39985/ |