clear up confusion about daily autocommit and systemd

there are two bugs in the Debian BTS that should probably be upstreamed here. I'm bundling them together because they are related, but it's true they are two distinct issues.

I bundle them because they somewhat depend on each other. Could you review those patches and see if they are appropriate?

They at least look good to me and I'm considering inclusion in the next upload...

Let me know! -- ?anarcat, your faithful debian packager...

RSS Atom

comment 1

Well, this seems like quite a mess at first glance.

The commit that added the timer claims that the timer is not enabled by default. If the timer is enabled by default, then everything that was done to intergrate it seems like it must rest on a faulty foundation.

Afaik, systemd does not enable a unit just because the file is dropped into /lib/systemd; it has to be enabled. So what is enabling it?

I checked a few systems, and they all had the timer enabled due to /etc/systemd/system/multi-user.target.wants/etckeeper.timer existing. git log seems to indicate the file got created before etckeeper's first commit to /etc. I do not know what creates it.

It seems to me we need to understand the root cause of what is enabling that to fix it.

The patch in 883263 adds some ugliness to the cron job to check if the timer is enabled. The patch 884824 in makes AVOID_DAILY_AUTOCOMMITS prevent the timer from committing. The way this is supposed to work is documented in etckeeper.conf:

# Etckeeper includes both a cron job and a systemd timer, which each
# can commit exiting changes to /etc automatically once per day.
# To enable the systemd timer, run: systemctl enable etckeeper.timer
# The cron job is enabled by default; to disable it, uncomment this next line.
#AVOID_DAILY_AUTOCOMMITS=1

The second patch would make that documentation be incorrect because it would also start disabling the timer. The first patch should not be necessary if that documentation is followed, except for the problem that the timer is apparently being wrongly enabled by default.

So I would rather understand and fix the root cause than patch over it in ways that add complexity and change the meaning of existing configurations.

(Alternatively, could just remove the cron job, remove AVOID_DAILY_AUTOCOMMITS and let the timer be disabled if the user doesn't want it, but that would need some explicit, understood mechanism that enables the timer. Or could just remove the timer.)

Comment by joey — Tue May 5 18:46:14 2020

Remove comment

comment 2

I tried, as an experiment, adding a copy of etckeeper.service and etckeeper.timer with a different name (netkeeper).

They were not enabled after writing the files, or after a systemctl daemon-reload. I even tried rebooting, and they're still not enabled.

Next experiment: I uninstalled etckeeper and deleted the symlink in /etc for its timer. systemd no longer had the timer enabled. I then reinstalled it with apt. systemd still didn't have the timer enabled, the symlink did not come back. (Even after rebooting.)

So, I'd think that there is no bug at all, except I am seeing the timer be enabled by that symlink on multiple machines, including a machine that I'm positive I've deployed entirely from configuration management. And I'm pretty sure I never manually enabled it on any of the machines I see it enabled on.

Maybe something used to cause the timer to get auto-enabled and no longer does?

Comment by joey — Tue May 5 19:16:58 2020

Remove comment

Add a comment