@acarvajal is that for your team? And if yes, how do I label it? With this label:[sap]? or [qe-sap]

maritawerner wrote in #note-1:

@acarvajal is that for your team? And if yes, how do I label it? With this label:[sap]? or [qe-sap]

Hello Marita. No, sys_param_check is handled now by QE-Core.

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: sys-param-check
https://openqa.opensuse.org/tests/3642278#step/Sysctl/1

To prevent further reminder comments one of the following options should be followed:

1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

The value of fs.inotify_max_user_watches seems to vary across runs

fs.inotify_max_user_watches is calculated with:

# CLAMP(num, min, max)
CLAMP(1% of total high ram, 2^13, 2^20)

The total high ram value is reported on /proc/meminfo under LowTotal:
https://github.com/torvalds/linux/blob/b85ea95d086471afb4ad062012a4d73cd328fa86/fs/proc/meminfo.c#L80

Is it possible to rewrite the test to validate the CLAMP min/max and then do a range check of:

APPROX_WATCHES=$((grep LowTotal -m 1 /proc/meminfo | awk '{$2=$2} END {print $2 ? $2 : '819200' }') ) / 100 ))

assert inotify between APPROX_WATCHES -1 and APPROX_WATCHES +

?

Proposal fix: https://github.com/openSUSE/sys-param-check/pull/9

It adds a 0.5% tolerance for the values that relay on RAM so they can vary within that threshold.

And updated the value of vm.max_map_count as per bsc#1214445