Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 2.14.0, Lustre 2.12.6
-
Ubuntu 20.04 clients
-
3
-
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.