http://bugzilla.opensuse.org/show_bug.cgi?id=1073204
http://bugzilla.opensuse.org/show_bug.cgi?id=1073204#c2
--- Comment #2 from Antoine Belvire
(In reply to Antoine Belvire from comment #0)
With snapshot 20171214, btrfsmaintenance has ineffectively switched to systemd timers.
Problems:
- Upon update from the old package to the new package, systemd timers are not present when doing a 'systemctl list-timers --all'. So no btrfs maintenance operation will be performed.
Over 4 year old bug in systemd-rpm-macros nobody did care to fix and now, after it got fixed, the packages got released in the wrong order :(
Oh, OK, then bad luck…
- The btrfsmaintenance-refresh.service, which was already pretty useless as it cannot be started by the try-restart %service_add_post, as it's a oneshot service, is worse now because it can only refresh cron symlinks. And as there is no protection in the refresh script to mutually exclude cron tasks and systemd timers, this may lead to have cron AND systemd timers activated for the same tasks.
The patch to switch btrfsmaintenance-refresh.service to systemd-timer did go lost when we debugged and fixed the systemd-rpm-macros bug ... Re-submitted.
OK, thanks! (For reference: it's sr#57815.)
- I don't see the point to keep the possibility to use cron tasks knowing that any update of the package will (try to) replace them by systemd timers. You'd better just remove the possibility to have cron tasks and remove the useless btrfsmaintenance-refresh.service, it would be simpler.
btrfsmaintenance-refresh.service is not useless, why do you think so? And in this case it's even quite handy to fix the broken systemd macros ... Removing the cron parts would be nice, but would also make the migration much more complicated.
I find btrfsmaintenance-refresh.service useless because: - It's never started automatically in spec file (because OneShot service, try-restart does nothing) - It's only started at boot time, I think. So someone who changes the periods in the config file has to reboot to apply them? He probably wouldn't wait and would call the refresh script and then there is no need to start the service at boot. - I mean maybe there is a usecase (make things consistent at boot time), but I'm a bit skeptical about this. Just my opinion though. Thanks again. -- You are receiving this mail because: You are on the CC list for the bug.