QA » openQA Project » openQA Tests

looks good:

https://openqa.opensuse.org/tests/664937#step/force_cron_run/

increase timeout to 120:

sub run {
select_console 'root-console';
# show dmesg output in console during cron run
assert_script_run "dmesg -n 7";
# Make sure there's no load before we trigger one via cron.
settle_load;
my $before = time;
assert_script_run "bash -x /usr/lib/cron/run-crons", 1000;
record_soft_failure 'bsc#1063638 - review I/O scheduling parameters of btrfsmaintenance' if (time - $before) > 120 && get_var('SOFTFAIL_BSC1063638');
sleep 3; # some head room for the load average to rise
settle_load;
# return dmesg output to normal
assert_script_run "dmesg -n 1";
}

got expected results (6 times):

http://e13.suse.de/tests/2448#step/force_cron_run/6

More test runs triggered now.

checked cron job rules:

## Type:         string
## Default:      ""
#
# At which time cron.daily should start. Default is 15 minutes after booting
# the system. Example setting would be "14:00".
# Due to the fact that cron script runs only every 15 minutes,
# it will only run on xx:00, xx:15, xx:30, xx:45, not at the accurate time
# you set.
DAILY_TIME=""
## Type:         integer
## Default:      5
#
# Maximum days not running when using a fixed time set in DAILY_TIME.
# 0 to skip this. This is for users who will power off their system.
#
# There is a fixed max. of 14 days set,  if you want to override this
# change MAX_NOT_RUN_FORCE in /usr/lib/cron/run-crons
MAX_NOT_RUN="5"

--

this is the problem I'm afraid...

There is another aspect here:
The check was added, AFAIK, to "flush" any btrfs maintenance jobs, to avoid these influence any later running jobs.

Now, the btrfs cron jobs have been migrated to systemd timers:

$> systemctl list-timers
NEXT                          LEFT                LAST                          PASSED             UNIT                         ACTIVATES
Thu 2018-05-17 19:00:00 CEST  59min left          Thu 2018-05-17 18:00:03 CEST  16s ago            snapper-timeline.timer       snapper-timeline.service
Fri 2018-05-18 00:00:00 CEST  5h 59min left       Thu 2018-05-17 00:00:05 CEST  18h ago            logrotate.timer              logrotate.service
Fri 2018-05-18 00:05:01 CEST  6h left             Thu 2018-05-17 01:59:50 CEST  16h ago            backup-sysconfig.timer       backup-sysconfig.service
Fri 2018-05-18 00:10:57 CEST  6h left             Thu 2018-05-17 00:20:53 CEST  17h ago            backup-rpmdb.timer           backup-rpmdb.service
Fri 2018-05-18 01:32:24 CEST  7h left             Thu 2018-05-17 01:11:32 CEST  16h ago            check-battery.timer          check-battery.service
Fri 2018-05-18 10:15:22 CEST  16h left            Thu 2018-05-17 10:15:22 CEST  7h ago             snapper-cleanup.timer        snapper-cleanup.service
Fri 2018-05-18 10:20:22 CEST  16h left            Thu 2018-05-17 10:20:22 CEST  7h ago             systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2018-05-21 00:00:00 CEST  3 days left         Mon 2018-05-14 00:00:08 CEST  3 days ago         btrfs-balance.timer          btrfs-balance.service
Mon 2018-05-21 00:00:00 CEST  3 days left         Mon 2018-05-14 00:00:08 CEST  3 days ago         btrfs-trim.timer             btrfs-trim.service
Mon 2018-05-21 00:00:00 CEST  3 days left         Mon 2018-05-14 00:00:08 CEST  3 days ago         fstrim.timer                 fstrim.service
Fri 2018-06-01 00:00:00 CEST  2 weeks 0 days left Tue 2018-05-01 00:00:08 CEST  2 weeks 2 days ago btrfs-scrub.timer            btrfs-scrub.service

It should be comparatively easy to check for any soon-expiring timers (LEFT column), and trigger the the corresponding services immediately. Hopefully, retriggering the services short time after will be cheap.

I run "bash -x /usr/lib/cron/run-crons" on just rebooted sles 15. No cron job got executed.

To me this command can work (it still depends on system timers.), but it has not to work as we assumed for executing cron jobs on a running system with very short online duration.

I'll ask coolo about this. We might think about to run each cron jobs separately. But at first I want to make sure about:

Summary: Avoid suprises later and run the cron jobs explicitly

http://e13.suse.de/tests/2518#step/force_cron_run/6

my $run_daily_cronjobs = 'for file in /etc/cron.daily/*; do echo execute daily cron jobs: $file; $file; done';
assert_script_run "$run_daily_cronjobs", 1000;

PR:

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5097

and once a week and once a months QA jobs still fail, as the weekly/monthly maintenance jobs suddenly run ...

updated:

find /etc/cron.{hourly,daily,weekly,monthly} -type f -executable -exec echo run cron job: {} \; -exec {} \;

info:
customers need to provide their own scripts for weekly, monthly, we don't provide packages for them, for hourly we have acronie-anacron which needs to be installed extra. systemd timers will replace cron job anyway. We can now check systemctl list-timers for details. but the question what should we do at moment.

coolo suggests to keep calling run-cron-jobs, but on top of it disable all systemd timers

PR updated now.

verification run:
http://e13.suse.de/tests/6070#step/force_cron_run (tw)
http://e13.suse.de/tests/6072#step/force_cron_run (sles 12 sp4)
http://e13.suse.de/tests/6077#step/force_cron_run (leap 15.0)

PR updated now:

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5097

PR merged, creating two tickets to handle:

• system_performance scenarios: https://openqa.opensuse.org/tests?match=system_performance
• renaming of force_cron_run