I am using a timer for this because if the machine is rebooted while the
job is in the middle of running then it needs to be retried after the
reboot, and that needs to keep happening until it runs to completion.
This is actually a somewhat common scenario since people are told to
reboot immediately after an update if a new kernel version was installed.
As far as I can tell, neither of the other two options you suggested,
`systemctl --no-block start` or `systemd-run`, will achieve the stated goal.
The timer approach I'm using seems like the most straightforward and
reliable.
If you have another suggestion that will achieve it without using a
timer, I'm all ears.
jik
On 9/25/24 10:45 PM, Josh Triplett wrote:
Package: apt-listchanges
Version: 4.6
Severity: normal
X-Debbugs-Cc:j...@joshtriplett.org
apt-listchanges installs a timer, apt-listchanges.timer, whose sole job
seems to be to attempt to run apt-listchanges.service, a service that
only needs to run once per machine, asynchronously rather than doing it
synchronously from the maintainer scripts.
Using a service for this seems entirely reasonable. However, there are
many different ways to kick off a service asynchronously. For instance,
you could use `systemctl --no-block start`, or for that matter use
`systemd-run` to run a transient unit. Both of those would avoid needing
to have a periodic timer.
