Bug#540202: include a cron reboot reminder

[dann frazier <dannf@debian.org>]

On Thu, Aug 06, 2009 at 09:34:23PM +0200, martin f krafft wrote:
> > Yeah, that might make sense - esp if there are other such
> > packages, but I can't think of any myself (thankfully). But
> > I think for the kernel case we would probably want that dropped-in
> > file to be managed by a more intelligent tool rather than trying
> > to figure things out (only) inside of maintainer scripts.
> 
> Ha! When I teach sysadmining courses, my students get to reboot
> their machines *all* *the* *time* (and they have to do exercises and
> brainstorming in the mean time). The reason is simply that anything
> could break, and if the next boot will fail, then I'd like to know
> *now*, not then.

Yeah, rebooting is certainly a good sysadmin practice, esp after a
significant upgrade, but I just can't think of many packages that
need to request a reboot from the admin during install/upgrade.

> > I do like the idea of a cronjob that checks periodically to see if
> > the kernel-that-would-be-booted-next is the same kernel that is
> > currently booted. It would be able to detect a mismatch introduced
> > outside of a dpkg operation - for example, if the the user
> > reconfigures which installed kernel is the default.
> 
> This is a twist on my proposal. All I wanted is a tool that knocks
> me over the head like "hey, you installed a new 2.6.30 last week and
> were to tired or unable to drive to the colo centre, or you were too
> much of a chicken to do a remote reboot. But you still have to do
> it. And till then, I'll mail you every day!"

It is a twist (well, an extension), but one I suspect users to
want. If you are running a 2.6.30 and install an updated 2.6.26 (or
vice-versa), do you want to be nagged everyday until you reboot? It
would be preferable to only nag if the default-kernel was updated
(either by installing 2.6.31 or an updated 2.6.30).

-- 
dann frazier