systemd timers don't work properly with non-default time periods

[automorphism88]

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.

[telkkar]

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