In an ideal world, I would suggest: - running it asynchronously from the maintainer script, - print a message from the maintainer script saying how to run the job manually if it gets interrupted, "or it will be run synchronously on the next apt upgrade", and - when apt-listchanges runs at upgrade time, if it hasn't yet been run, run it synchronously then.
On Thu, 26 Sep 2024 09:48:01 -0400 Jonathan Kamens <j...@kamens.us> wrote: > 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. > >
