[LU-11749] sanity-sec test 23b fails with 'Should return gid=60010 or 60010 on client2' Created: 10/Dec/18 Updated: 10/May/19 Resolved: 06/Feb/19 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.12.0 |
| Fix Version/s: | Lustre 2.13.0, Lustre 2.12.2 |
| Type: | Bug | Priority: | Minor |
| Reporter: | James Nunez (Inactive) | Assignee: | Sebastien Buisson |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
sanity-sec test_23b started failing on October 30, 2018 with 'Should return gid=60010 or 60010 on client2' Looking at the client test_log from a recent failure, https://testing.whamcloud.com/test_sets/1e06f64c-f9d7-11e8-b216-52540065bddc , we see an issue parsing output CMD: onyx-41vm12 /usr/sbin/lctl list_nids | grep tcp | cut -f 1 -d @ waited 5 seconds for sync getfacl: Removing leading '/' from absolute path names CMD: onyx-41vm9.onyx.whamcloud.com getfacl /mnt/lustre/d23b.sanity-sec getfacl: Removing leading '/' from absolute path names CMD: onyx-41vm9.onyx.whamcloud.com getent passwd /usr/lib64/lustre/tests/sanity-sec.sh: line 1834: [: sanityusr: integer expression expected sanity-sec test_23b: @@@@@@ FAIL: Should return gid=60010 or 60010 on client2 This issue may be caused by the landing of the patch for LU-9795 https://review.whamcloud.com/28662. From sanity-sec test_23b, the code that fails is 1799 local fs_id=$((IDBASE+10)) … 1828 # getfacl default acl on client2 (mapped gid=60010) 1829 mapped_id=$(do_node ${clients_arr[1]} getfacl $testdir | 1830 grep -E "default:group:.*:rwx" | awk -F: '{print $3}') 1831 fs_user=$(do_node ${clients_arr[1]} getent passwd | 1832 grep :$fs_id:$fs_id: | cut -d: -f1) 1833 [ -z "$fs_user" ] && fs_user=$fs_id 1834 [ $mapped_id -eq $fs_id -o "$mapped_id" = "$fs_user" ] || 1835 error "Should return gid=$fs_id or $fs_user on client2" 1836 sanity-sec test 23b requires two clients. The test can be kicked off/run on either client 1 or client 2. The issue may be that getfacl and getent needs to be run on the client that is not kicking off the test. In the failures, the test is being run on client 2, but looking at (a small number of) tests that pass, the test is kicked off on client 1. More failures are at: |
| Comments |
| Comment by Peter Jones [ 12/Dec/18 ] |
|
Sebastien Could you please advise on this issue? Thanks Peter |
| Comment by Sebastien Buisson [ 13/Dec/18 ] |
|
Nice catch James! There is an issue with the test itself, not the feature being tested. The problem is indeed due to the fact that, for some reason that I was not aware of, it happens that the client on which the test is kicked off is not necessarily client 1. I will push a patch to fix this issue in the test. Thanks, |
| Comment by Gerrit Updater [ 13/Dec/18 ] |
|
Sebastien Buisson (sbuisson@ddn.com) uploaded a new patch: https://review.whamcloud.com/33846 |
| Comment by Gerrit Updater [ 06/Feb/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/33846/ |
| Comment by Peter Jones [ 06/Feb/19 ] |
|
Landed for 2.13 |
| Comment by Gerrit Updater [ 09/Apr/19 ] |
|
James Nunez (jnunez@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/34623 |
| Comment by Gerrit Updater [ 10/May/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/34623/ |