action #98991


[qe-core][qem][sporadic] test fails in autofs_client

Added by dzedro over 2 years ago. Updated about 2 years ago.

Bugs in existing tests
Target version:
Start date:
Due date:
% Done:


Estimated time:
QE-Core: April Sprint (Apr 13 - May 11)



This failure is happening occasionally, is probably just because of performance.
Add some post fail hook check to test connection, autofs daemon, etc. or retry on the failing ls.

openQA test in scenario sle-15-SP3-Server-DVD-Updates-x86_64-mau-autofs-client@64bit fails in

Test suite description

Testsuite maintained at Maintainer: QE Core


Fails since (at least) Build 20210921-1 (current job)

Expected result

Last good: 20210920-2 (or more recent)

Further details

Always latest result in this scenario: latest

Related issues 1 (0 open1 closed)

Related to openQA Tests - action #102251: [qe-core] test fails in autofs_client - Directory not found after autofs has been startedResolveddvenkatachala

Actions #1

Updated by tjyrinki_suse over 2 years ago

  • Subject changed from [qe-core][qem] test fails in autofs_client to [qe-core][qem][sporadic] test fails in autofs_client
  • Status changed from New to Workable
  • Start date deleted (2021-09-21)
Actions #2

Updated by szarate over 2 years ago

  • Related to action #102251: [qe-core] test fails in autofs_client - Directory not found after autofs has been started added
Actions #3

Updated by apappas over 2 years ago

  • Target version set to QE-Core: Ready
  • Parent task set to #102215
Actions #4

Updated by tjyrinki_suse over 2 years ago

  • Status changed from Workable to In Progress

Duplicate of , which is in progress

Actions #5

Updated by tjyrinki_suse over 2 years ago

  • Assignee set to dvenkatachala
Actions #6

Updated by dvenkatachala over 2 years ago

I am seeing below error messages in autofs_client-journal.log whenever the test fails.

Feb 07 02:44:31.065660 client automount[2991]: dev_ioctl_send_fail: token = 2
Feb 07 02:44:31.069752 client automount[2991]: failed to mount /mnt/test/test
Feb 07 02:44:32.329930 client kernel: sysrq: Show State
Feb 07 02:44:32.330088 client kernel: task:systemd         state:S stack:    0 pid:    1 ppid:     0 flags:0x00000000
Feb 07 02:44:32.330144 client kernel: Call Trace:
Feb 07 02:44:32.330201 client kernel:  __schedule+0x2fd/0x750
Feb 07 02:44:32.330253 client kernel:  schedule+0x2f/0xa0
Feb 07 02:44:32.330304 client kernel:  schedule_hrtimeout_range_clock+0xee/0x100
Feb 07 02:44:32.330369 client kernel:  ? ep_read_events_proc+0xd0/0xd0
Feb 07 02:44:32.330426 client kernel:  ? ep_scan_ready_list.constprop.20+0x196/0x1d0
Feb 07 02:44:32.330478 client kernel:  ep_poll+0x3d4/0x4d0
Feb 07 02:44:32.330529 client kernel:  ? wait_woken+0x80/0x80
Feb 07 02:44:32.330579 client kernel:  do_epoll_wait+0xab/0xc0
Feb 07 02:44:32.330629 client kernel:  __x64_sys_epoll_pwait+0x45/0xb0
Feb 07 02:44:32.330681 client kernel:  do_syscall_64+0x5b/0x1e0
Feb 07 02:44:32.330731 client kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Feb 07 02:44:32.330782 client kernel: RIP: 0033:0x7f43cc146f76
Feb 07 02:44:32.330847 client kernel: Code: Bad RIP value.
Feb 07 02:44:32.330908 client kernel: RSP: 002b:00007ffc8ca03ff0 EFLAGS: 00000293 ORIG_RAX: 0000000000000119
Feb 07 02:44:32.330961 client kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f43cc146f76
Feb 07 02:44:32.331016 client kernel: RDX: 0000000000000031 RSI: 00007ffc8ca04030 RDI: 0000000000000004
Feb 07 02:44:32.331068 client kernel: RBP: 00007ffc8ca04030 R08: 0000000000000000 R09: 0000000000000008
Feb 07 02:44:32.331119 client kernel: R10: ffffffffffffffff R11: 0000000000000293 R12: 0000000000000000
Feb 07 02:44:32.331170 client kernel: R13: ffffffffffffffff R14: 00007ffc8ca04030 R15: 0000000000000001
Feb 07 02:44:32.331221 client kernel: task:kthreadd        state:S stack:    0 pid:    2 ppid:     0 flags:0x80004000

From my understanding its looks like bug and issue happens sporadically.
Santiago, Can you please help me in this case to investigate more.

Actions #7

Updated by okurz over 2 years ago

That output is actually not a bug. The line "sysrq: Show State" shows that with "sysrq-w" the kernel was requested to dump tasks that are in uninterruptable (blocked) state. That's being done as part of the post_fail_hook. So the test did fail but what you see is not the error itself but additional output than may help you in investigation. Also see for more information on that

Actions #8

Updated by szarate about 2 years ago

  • Status changed from In Progress to Feedback

Hey, can we close this ticket? or is there something else needed?

Actions #9

Updated by dvenkatachala about 2 years ago

I have executed many times in my local setup and test is working as expected. Test failed only once 27 days back and same test is passed in rerun.
Can we accept this and close this ticket?

Actions #10

Updated by dvenkatachala about 2 years ago

  • Status changed from Feedback to Resolved
Actions #11

Updated by szarate about 2 years ago

  • Sprint set to QE-Core: April Sprint (Apr 13 - May 11)

Also available in: Atom PDF