Re: "Service restarts being deferred"

[Jesper Dybdal <jd-debian-user@dybdal.dk>]

On 2020-12-22 15:34, David Wright wrote:
> On Sun 20 Dec 2020 at 17:01:31 (+0100), Jesper Dybdal wrote:
> > On 2020-12-19 21:05, Kushal Kumaran wrote:
> > > > > Jesper Dybdal wrote:
> > > > > > I run Buster with unattended updates configured to allow reboots.
> > > > > >
> > > > > > Sometimes after an update, the log contains:
> > > > > > > Service restarts being deferred:
> > > > > > > ??systemctl restart systemd-logind.service
> > > > > > > ??systemctl restart unattended-upgrades.service
> > > >From the documentation of Automatic-Reboot, it only has effect for
> > > updates that result in the /var/run/reboot-required file being created.
> > >
> > > For service restarts, the needrestart configuration would be a better
> > > place to start.  The comments in /etc/needrestart/needrestart.conf are
> > > instructive:
> > >
> > >       # do not restart oneshot services, see also #862840
> > >       qr(^apt-daily\.service$) => 0,
> > >       qr(^apt-daily-upgrade\.service$) => 0,
> > >       qr(^unattended-upgrades\.service$) => 0,
> > >
> > >       # don't restart systemd-logind, see #798097
> > >       qr(^systemd-logind) => 0,
> > >
> > > Do go through those bug reports and experiment at a safe time before
> > > changing things here.
> > Thanks.  Those bug reports explain why those services are not simply
> > restarted, which seems very sensible.
> >
> > But the "deferred" restarts seem to be deferred indefinitely, until
> > the next reboot.  So I still don't quite understand why an automatic
> > reboot is not scheduled in order to get those services restarted.
> I would presume a reboot is not scheduled because a reboot is not seen
> as a requirement just to restart the odd service: there are separate
> commands for that.

If a server is truly unattended, then it needs unattended-upgrades to 
somehow manage to restart services that it has upgraded.
And if there are good reasons why these specific services cannot simply 
be restarted directly by unattended-upgrades without a reboot (as the 
bug reports referenced above indicate), then it would seem natural to me 
to use the existing mechanism to get a reboot done after upgrading.  
That mechanism works fine after for instance a kernel upgrade.

Requiring manual intervention to restart an upgraded service would 
defeat the purpose of unattended-upgrades.

> But I would also ask how the system is to determine a scheduled time
> or occasion to restart services/reboot the system. What criteria, as
> sysadmin, do you currently use to make those decisions for yourself?

The existing mechanism used after kernel upgrades does it just fine.

--
Jesper Dybdal
https://www.dybdal.dk