On 29.01.19 14:32, Richard Brown wrote:
On Tue, 29 Jan 2019 at 14:01, Ludwig Nussel
wrote: Please don't. But wan't this about boot times? The rpmdb backup is not a boot time service, is it? It is: [Timer] Persistent=true
Persistent=true has really bad sideeffects, I removed it meanwhile from my timers everywhere. Well, not everywhere as backup-rpmdb.timer still has it :-) Mind catching up on it? Are there any other side effects besides firing at system boot? If you have a number of persistent timers and they all didn't run at their regular assigned times, then your boot suddenly has ALL of them running at that boot
The combined impact of stuff like btrfs-balance, fstrim, and backup-rpm DB all running at once can be very painful for many machines
A judgement call has to be made - persistent=true should only be set on timers that absolutely, positively must run as close as possible to the desired time interval.
I would argue for anything that can be described as a 'nice to have maintenance cleanup', then "old-fashioned" cron-like behaviour of "if I wasn't booted when I should have run, I'll run it at my regular time next time" is better for many of the things we're talking about here.
But, ultimately, for backup-rpmdb, I think it's bonkers we're still running it at all - our default btrfs snapshots take care of that and for anyone who neglects to use that feature, they really should be taking their own backups of /usr/lib/sysimage just as they should of /etc and any user data in /srv or /var they care about.
I don't think disabling backup-rpmdb is necessary on desktop machines, this thread started by looking at long raspi 3 boots, which has differences to the default install already, mainly ext4 (as btrfs with cow would not be bearable). The main problem with the raspi3 boot and those triggers consists of the raspi3 not having a hw clock and those triggers getting started too early in the boot process. So the trigger gets a scheduled time to run (buldtime + X) and when we adjust the clock with ntpd to the current time, the triggers do what they are designed for: Trigger the services immediately. (And that seems to be the same every boot). backup-rpmdb.timer on a fresh boot just now: ● backup-rpmdb.timer - Backup of RPM database Loaded: loaded (/usr/lib/systemd/system/backup-rpmdb.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2018-12-04 13:20:59 UTC; 1 months 25 days ago Trigger: Wed 2019-01-30 01:00:11 UTC; 10h left Dez 04 13:20:59 localhost.localdomain systemd[1]: Started Backup of RPM database. same with the other triggers (same boot): 4min 28.783s mandb.service 4min 21.783s fstrim.service 3min 883ms postfix.service 2min 26.452s backup-rpmdb.service 1min 38.266s backup-sysconfig.service 27.245s logrotate.service ... So in conclusion starting the triggers after time adjustment (ntpd, chrony) would hopefully solve this problem for the raspi and any other machine with no hw clock (or emtpy bios battery). Greetings, Tobias -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org