[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
Subject: LU-13960 tests: correct usage of _var variable
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: f4355c25a6580c09361d73ff22b57bbf25e634f1

Comment by Gerrit Updater [ 19/Sep/20 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/39891/
Subject: LU-13960 tests: correct usage of _var variable
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ff29ed8fe9c58bd2caa4d63bcbe7556e1c320703

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
Subject: LU-13960 tests: correct usage of _var variable
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: 58ca27667763994d8173e5c6cea2f885486521d6

Comment by Gerrit Updater [ 22/Oct/20 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/39985/
Subject: LU-13960 tests: correct usage of _var variable
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 284595fe2aa0c3898fbb3330e50cb669102a92d1

Generated at Sat Feb 10 03:05:40 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.