Snapper Timeline, use systemd service instead of cron.hourly job

[ntasos]

Hello everyone.
I've enabled timeline snapshots but I don't want them to be created every hour.
So I deleted suse.de-snapper inside /etc/cron.hourly directory and edited snapper-timeline.timer service so that snapshots are created every six hours.
The problem is that when snapper package is updated suse.de-snapper is re-created.
I guess it's not safe to completely disable the cron daemon since there are various files (btrfs maintenance tools) inside cron.* directories.

[tsu2]

The reason why you lost your changes is because you didn't follow the correct procedure for editing an existing systemd Unit file.

So, for instance all systemd system Unit files will be found in

/usr/lib/systemd/system/

Never, ever edit the original files in the above location.
Besides what you've found that the files will be replaced if updated, if you make a mistake you will not be able to easily return to the default unless you made a copy of it.

Instead, for whatever Unit file you want to customize,
copy the Unit file to

/etc/systemd/system/

And edit your copy.
When your system boots up, it will always look for files in this location and if a file with the same name is found with the same name as what is in the default location, your copy will always over-ride.
And, as I described if you ever want to return to the system default, just delete your copy.

HTH,
TSU

[ntasos]

Never, ever edit the original files in the above location.
Besides what you've found that the files will be replaced if updated, if you make a mistake you will not be able to easily return to the default unless you made a copy of it.

I probably didn't explain myself correctly.
My trouble is not with systemd. I did copy the unit files in /etc/systemd/system and it's working as expected.

I'm looking for a way to disable ,once and for all, the cron job from creating timeline snapshots and handle them only with systemd.

[tsu2]

There probably isn't a 100% solution, but I suppose that after you modify the cron files however you want, you could remove the write permission from those files... That would solve over-writing by an upgrade but if there were some kind of significant reason to modify like a security patch, that important fix wouldn't be applied. But, maybe in <this specific instance> that wouldn't be a concern.

For something this small and simple, editing the file permissions directly might be practical.
For something more extensive, then modifying an apparmor or selinux policy might make more sense.

TSU