Open automorphism88 opened 2 years ago
The behavior you're describing sounds like OnCalendar
isn't being reset before the directive in the schedule.conf file.
Some references: See last sentence of systemd.timer systemd.unit
From systemd.unit specifically:
Note that for drop-in files, if one wants to remove entries from a setting that is parsed as a list (and is not a dependency), such as AssertPathExists= (or e.g. ExecStart= in service units), one needs to first clear the list before re-adding all entries except the one that is to be removed.
I'm not sure how to tell exactly if OnCalendar is a setting that systemd parses as a list, but something like this is probably what the change would look like in btrfsmaintenance-refresh-cron.sh. Note the OnCalendar=
line
mkdir -p /etc/systemd/system/"$SERVICE".timer.d/
cat << EOF > /etc/systemd/system/"$SERVICE".timer.d/schedule.conf
[Timer]
OnCalendar=
OnCalendar=$PERIOD
EOF
systemctl enable "$SERVICE".timer &> /dev/null
EDIT1: Looks like this should be addressed by the changes in the devel branch. https://github.com/kdave/btrfsmaintenance/blob/0a792e63839edc608cdc20a9e74ac47581571ad2/btrfsmaintenance-refresh-cron.sh#L82
I changed the scrub period in
/etc/sysconfig/btrfsmaintenance
from monthly to weekly, and it seems that when using systemd timers,btrfsmaintenance-refresh.service
implements this change by creating a file/etc/systemd/system/btrfs-scrub-timer.d/schedule.conf
to make the timer trigger weekly. However, it seems the effect is to make the timer start both monthly and weekly. I noticed that it activated today on the 1st of the month, even though it had just activated two days ago at the beginning of the week. I don't believe that that is the intended behavior, and it only happens with the systemd timers, not if you use cron.