Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #229840 > unrolled thread

"Service restarts being deferred"

Back to article view | Back to linux.debian.user

Contents

  "Service restarts being deferred" Jesper Dybdal <jd-debian-user@dybdal.dk> - 2020-12-19 16:40 +0100
    Re: "Service restarts being deferred" Dan Ritter <dsr@randomstring.org> - 2020-12-19 17:20 +0100
      Re: "Service restarts being deferred" Jesper Dybdal <jd-debian-user@dybdal.dk> - 2020-12-19 18:40 +0100
        Re: "Service restarts being deferred" Kushal Kumaran <kushal@locationd.net> - 2020-12-19 21:10 +0100
          Re: "Service restarts being deferred" Jesper Dybdal <jd-debian-user@dybdal.dk> - 2020-12-20 17:10 +0100
            Re: "Service restarts being deferred" David Wright <deblis@lionunicorn.co.uk> - 2020-12-22 15:40 +0100
              Re: "Service restarts being deferred" Jesper Dybdal <jd-debian-user@dybdal.dk> - 2020-12-23 18:30 +0100
                Re: "Service restarts being deferred" Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-23 19:40 +0100
                  Re: "Service restarts being deferred" David Wright <deblis@lionunicorn.co.uk> - 2020-12-24 02:30 +0100

#229840 — "Service restarts being deferred"

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

I don't understand why these services are not restarted, if necessary 
through a reboot.

I want my system to be able to run truly unattended for a long time, so 
necessary restarts should be done without waiting for manual 
intervention.  And if the restarts are not necessary, why are they there 
at all, though deferred?

So what have I misunderstood?

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

[toc] | [next] | [standalone]

#229841

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
> 
> I don't understand why these services are not restarted, if necessary
> through a reboot.
> 
> I want my system to be able to run truly unattended for a long time, so
> necessary restarts should be done without waiting for manual intervention.??
> And if the restarts are not necessary, why are they there at all, though
> deferred?
> 
> So what have I misunderstood?

In your /etc/apt/apt.conf.d,  edit a file named 50unattended-upgrades

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
Unattended-Upgrade::Automatic-Reboot "true";

// Automatically reboot even if there are users currently logged
// in.
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";

Without those two lines, you get the behavior you currently
have.

Not everyone wants automatic reboots; not everyone wants
automatic reboots even with someone logged in.

-dsr-

[toc] | [prev] | [next] | [standalone]

#229845

On 2020-12-19 17:14, Dan Ritter 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
>> I don't understand why these services are not restarted, if necessary
>> through a reboot.
>>
>> I want my system to be able to run truly unattended for a long time, so
>> necessary restarts should be done without waiting for manual intervention.??
>> And if the restarts are not necessary, why are they there at all, though
>> deferred?
>>
>> So what have I misunderstood?
> In your /etc/apt/apt.conf.d,  edit a file named 50unattended-upgrades
>
> // Automatically reboot *WITHOUT CONFIRMATION* if
> //  the file /var/run/reboot-required is found after the upgrade
> Unattended-Upgrade::Automatic-Reboot "true";
>
> // Automatically reboot even if there are users currently logged
> // in.
> Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
>
> Without those two lines, you get the behavior you currently
> have.
>
> Not everyone wants automatic reboots; not everyone wants
> automatic reboots even with someone logged in.

Thanks.
I already have Automatic-Reboot set, and it correctly causes reboot 
after for instance kernel upgrades.
I do not have Automatic-Reboot-WithUsers set, since I did not imagine it 
would make a difference when there actually are no users logged in.
But I'll try setting it also and see if that somehow makes a difference.

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

[toc] | [prev] | [next] | [standalone]

#229849

On Sat, Dec 19 2020 at 06:34:35 PM, Jesper Dybdal <jd-debian-user@dybdal.dk> wrote:
> On 2020-12-19 17:14, Dan Ritter 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
>>> I don't understand why these services are not restarted, if necessary
>>> through a reboot.
>>>
>>> I want my system to be able to run truly unattended for a long time, so
>>> necessary restarts should be done without waiting for manual intervention.??
>>> And if the restarts are not necessary, why are they there at all, though
>>> deferred?
>>>
>>> So what have I misunderstood?
>> In your /etc/apt/apt.conf.d,  edit a file named 50unattended-upgrades
>>
>> // Automatically reboot *WITHOUT CONFIRMATION* if
>> //  the file /var/run/reboot-required is found after the upgrade
>> Unattended-Upgrade::Automatic-Reboot "true";
>>
>> // Automatically reboot even if there are users currently logged
>> // in.
>> Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
>>
>> Without those two lines, you get the behavior you currently
>> have.
>>
>> Not everyone wants automatic reboots; not everyone wants
>> automatic reboots even with someone logged in.
>
> Thanks.
> I already have Automatic-Reboot set, and it correctly causes reboot
> after for instance kernel upgrades.
> I do not have Automatic-Reboot-WithUsers set, since I did not imagine
> it would make a difference when there actually are no users logged in.
> But I'll try setting it also and see if that somehow makes a difference.

>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.

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#229861

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.
(Unless it is, strangely, the "Reboot with users" setting that has some 
influence here, even though there are no logged in users in my case.)

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

[toc] | [prev] | [next] | [standalone]

#229916

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.

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?

> (Unless it is, strangely, the "Reboot with users" setting that has
> some influence here, even though there are no logged in users in my
> case.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#229949

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

[toc] | [prev] | [next] | [standalone]

#229953

[Multipart message — attachments visible in raw view] — view raw

On Mi, 23 dec 20, 18:28:43, Jesper Dybdal wrote:
> 
> 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.

I'm guessing when the mechanism was designed it didn't even consider the 
possibility of services that can't be safely restarted, so it's limited 
to the kernel.

It's probably possible to extend unattended-upgrades to consider 
services in addition to kernel upgrades, (with some sort of 
include/exclude mechanism) though this needs to be programed.

You could start by filing a (wishlist) bug.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#229959

On Wed 23 Dec 2020 at 20:31:09 (+0200), Andrei POPESCU wrote:
> On Mi, 23 dec 20, 18:28:43, Jesper Dybdal wrote:
> > 
> > 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.
> 
> I'm guessing when the mechanism was designed it didn't even consider the 
> possibility of services that can't be safely restarted, so it's limited 
> to the kernel.

Wich mechanism? I'm now not sure that the OP picked up on
Kushal Kumaran's pointing out the abilities of needrestart.

> It's probably possible to extend unattended-upgrades to consider 
> services in addition to kernel upgrades, (with some sort of 
> include/exclude mechanism) though this needs to be programed.
> 
> You could start by filing a (wishlist) bug.

I think you would be reinventing needrestart. I get the impression¹
that unattended-upgrades does the business of downloading and
installing updates, with configuration limited to (roughly) when,
circumstances (eg AC power), autoremoving and rebooting.

OTOH needrestart has fine-grained configuration at the level of
individual services, and can list or restart them (automatically
or interactively), and it provides hooks for any other sort of
decision-making exercise, hence my question above about the
OP's criteria.

One might assume that even a "truly unattended" system is sending
some sort of notification to a sysadmin somewhere, and so that too
is configurable in needrestart.

¹ I don't use unattended-upgrades myself, but just a cron job to
  download potential candidates and notify me.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web