The installation/upgrade of some packages reloads the systemd daemons,
which occasionally has the effect to execute the apt-daily service,
which runs "/usr/lib/apt/apt.systemd.daily update".

This is silly, because precisely at this time, either there already
is a /var/lib/dpkg/lock-frontend lock (due to the installation) and
the command fails, or if the frontend, like aptitude, releases the
lock temporarily, this may make installation by the frontend fail.
In any case, this is not satisfactory.

If the "apt.systemd.daily update" must be run at this time (reload
of systemd daemons), there is a major problem. Otherwise, it should
be run at a later time, so that there is a high probability that
the installation has finished, avoiding a lock failure. Or why not
completely relying on a randomized timer?

As I mentioned in the other thread, we do not do anything with the
systemd services. We do restart the timers, which I guess could mess
up the randomization or something?

But I don't know, I'd need more info from systemd people.

[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true

and it seems that

  systemctl --system daemon-reload >/dev/null || true

sometimes has the effect to execute the service immediately, thus
ignoring the randomization.

If randomization is currently ignored for some reason, there should
at least be an option to preserve the randomization at the reload
of the daemons. The observed behavior of systemd does not seem to
be documented in the systemd.timer(5) man page.