stress-ng is causing a kernel reboot by stat'ing a /dev entry

[Colin Ian King]

Hi there,

always see hard resets (no logs, no messages) on different machines if they run the fstat stressor (even one stressor is enough). Cause I see this behaviour on different systems I assume that this is not hardware error but a may be a bsic problem of the stressor itself, could it? MOst of the systems use a RAID controller, but different models, stress-ng is running on RAID volumes.

Or any ideas how to "debug" what's going on then during a fstat run? Verbosity does not show me any hint...

Thank you in advance
Martin

[Colin Ian King (colin-king)]

From https://answers.launchpad.net/ubuntu/+source/stress-ng/+question/271204

[Colin Ian King (colin-king)]

The fstat stressor is basically just stat'ing a load of files in /dev, so it looks like an open()... fstat() ... close() or a stat() on a /dev/ entry is causing the kernel some issues. Are you running stress-ng as root or not?

One way to see what is happening is to log in remotely and run strace on stress-ng, this will capture the moment when a particular /dev is accessed.. So run:

strace -f stress-ng --fstat 1

and see where it hangs. This looks like stress-ng has found a kernel bug, so I'd be interested in seeing what happens, and which kernel you are running on.

[Colin Ian King (colin-king)]

No update for 4 weeks, waiting on user to report back from https://answers.launchpad.net/ubuntu/+source/stress-ng/+question/271204, will mark this as won't fix.