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
Attachment:
signature.asc
Description: PGP signature