Move to Systemd Timers or at least drop Cronie dependency

[bkmo]

We are pretty much in a Systemd world now. Can Timeshift be configured to use Systemd timers as opposed to using Cronie cron jobs?
It is possible to do now, but cronie has to be kept installed and masked for Timeshift to function. All that is needed is 2 timers and services files for a boot and hourly timer.

[dataprolet]

Maybe take a look at this AUR package as a reference.

[bkmo]

The timer and service are not a problem. I just don't like that cronie is a dependency and Timeshift won't run without it. It would be nice to see cronie not be installed on a systemd enabled OS.

[ludvigng]

The above pull request adds systemd timer support for timeshift. I originally made the files around 2 years ago, but I haven't tested it since, so be wary.

[bkmo]

All well and good, but it doesn't issue the dependence on cronie. Thank you

[ludvigng]

Well, no, not immediately. I can't really do anything about that since I wouldn't have access to the mint repos. But if the pull gets accepted then it should fix the issue, since cron would no longer be needed for automatic snapshots. :)

[bkmo]

Please do not add this PR as it is a half-baked solution. Cronie needs to be dealt with manually, there is no boot service, etc. Cronie is a dpendency of Timeshift, and it won't run without it. So unless you disable and/or mask it then you still have the original schedules running. So those able to do this manually should also be able to do there own systemd timer/services.

[ludvigng]

What exactly is half-baked about it? The cron integration is just a single command ran every hour, and the timer will do the same thing. The systemd timer isn't enabled by default, and thus will do nothing by default, but by having the timer file available the user can choose:

1. If they already have cronie installed, then nothing will change
2. If they don't have cronie installed or enabled and don't want to use cron, then they can run systemctl enable timeshift.timer to use the systemd timer instead.

By having the option here, the package maintainers can choose whether cronie would be a hard dependency or just a recommends. It'd allow people to completely remove or disable cronie and still have a way timeshift work. Not shipping the systemd files will mean that cronie stays a hard dep, since it'd break functionality of the program.

Last time I checked the timeshift app didn't do any checks on whether cron was running on the system, so it ran just fine without it. Maybe that's changed.

Yeah, it's missing the service on boot, I'm not sure if that was a thing when I originally wrote this in 2021. Feel free to add it if you think it's something necessary, I don't really want to install and set up timeshift to test when it's not something I'm using anymore. I'm not sure how you expect things to change without adding support for the timer system first though, what exactly is your ideal solution here?

[bkmo]

Timeshift checks for the existence of cron and will not run without it. That is why it is a hard dependency. I feel that unless that issue can be handled by the developers then just adding timers is kind of useless. That being said they has been an AUR package for Arch that sets up and runs the timers. Hourly, and boot. Thank you for your work.

[nikelborm]

+1 It would be great to remove cron/cronnie from timeshift. It's sad that timeshift can't run without cronnie when systemd timers are available. Systemd timers are not hard, but has more custom capabilities, and users can extend or edit .service and .timer files created by timeshift.

Simple explanation of timers

[Cherkah]

The systemd timer isn't enabled by default, ... by having the timer file available the user can choose

pushing systemd-timers and lets linux users to chose between cron/timers should be the way to refresh this so nice soft (the 1rst one ?) in the field of desktop backup graphical applications .

...whether cronie would be a hard dependency...
...so it ran just fine without it' ....

This does not make sense given the proven established robustness of Systemd and the future seems focused on more Systemd. but I also recognize that some people don't want to use it!

hope the PR #190 will be merged soon.