action #25554
closed
[functional][bsc#1063638][u] soft fail in force_cron_run is too strict
Added by okurz over 6 years ago.
Updated almost 6 years ago.
Category:
Enhancement to existing tests
Description
Observation¶
openQA test in scenario sle-15-Leanos-DVD-Staging:G-x86_64-gnome@64bit-staging fails in
force_cron_run
but the mentioned bug in the soft fail should be already fixed.
Problem¶
Probably the check is too strict.
[25 Sep 2017 09:59:15] <okurz> coolo: https://openqa.opensuse.org/tests/491791#step/force_cron_run/6 looks to me as if it won't get any better
[25 Sep 2017 10:22:17] <coolo> okurz: one way could be settling load *before* the crons?
[25 Sep 2017 10:22:31] <coolo> but havig a load of 0.3 for unused X sounds like a bug - a different one though :)
[25 Sep 2017 10:27:19] <okurz> hm, settle load before crons, execute them, check again, that could work. I wonder though if you have a good test scenario in mind which one could trigger 500 times to check if the bug is really solved or another one stopping us now
Further details¶
Always latest result in this scenario: latest
- Related to action #19476: [migration]test fails in force_cron_run by assert_script_run failed added
- Related to action #21798: [functional]test fails in force_cron_run, idle threshold to high added
- Related to action #23556: [sle][functional]test fails in force_cron_run because of missing file /usr/lib/cron/run-crons added
- Related to action #28364: [sle][functional] remove reference to "btrfs cron jobs kills system responsiveness"-bug and workaround in console/force_cron_run added
- Related to action #27597: [sle][functional] test fails in force_cron_run - Wrong bug ticket assigned added
- Subject changed from soft fail in force_cron_run is too strict to [functional]soft fail in force_cron_run is too strict
- Due date set to 2018-01-16
- Target version set to Milestone 13
- Due date changed from 2018-01-16 to 2018-01-30
mass-shift of tickets to next sprint due to training on sprint review day
- Due date changed from 2018-01-30 to 2018-02-13
- Subject changed from [functional]soft fail in force_cron_run is too strict to [functional][bsc#1063638]soft fail in force_cron_run is too strict
- Due date changed from 2018-02-13 to 2018-05-15
- Status changed from New to Blocked
- Target version changed from Milestone 13 to Milestone 15
Now test tracks bsc#1063638, will set ticket to blocked and review progress on bug later.
- Related to action #31351: [functional][u][medium] force_cron_run does not actually run any crons (occasionally) added
Currently settle_load reports any time above 30 seconds as a softfailure, which is too short IMHO:
- load average (first value) is a 1 minute sliding window average. Even for a completely idle system this value can be arbitrarily large for any time < 1 minute.
- force_cron_run is executed immediately after boot, some large values (>>= 1) in the window are to be expected
- starting top will likely contribute to the load (once), as processes waiting for disk I/O contribute to the load value.
A timeout of 70 seconds (60 seconds window plus startup) is likely more appropriate.
That sounds very reasonable. We should do that, switch to 70 seconds.
- Due date changed from 2018-05-15 to 2018-05-08
- Subject changed from [functional][bsc#1063638]soft fail in force_cron_run is too strict to [functional][bsc#1063638][u]soft fail in force_cron_run is too strict
- Subject changed from [functional][bsc#1063638][u]soft fail in force_cron_run is too strict to [functional][bsc#1063638][u] soft fail in force_cron_run is too strict
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
- Target version changed from Milestone 15 to Milestone 16
I found that bsc#1063638 is not fixed yet.
record_soft_failure 'bsc#1063638' if (time - $before) > (is_jeos() ? 180 : 30);
- Status changed from Workable to In Progress
it looks good, no softfailed now.
Please collect more statistics on this, e.g. run at least 20 jobs
- Due date changed from 2018-05-08 to 2018-05-22
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
Also available in: Atom
PDF