Bug#540202: include a cron reboot reminder
Package: linux-2.6 Severity: wishlist Maybe the linux-image packages could install a cron.daily script that compared the currently installed version to /proc/version and sent an e-mail to root in case there's a mismatch, which most likely means that a new kernel exists, but the machine has not been rebooted. Extra bonus for making this debconf configurable. ;) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#540202: include a cron reboot reminder
On Thu, Aug 06, 2009 at 05:46:20PM +0200, martin f krafft wrote: Package: linux-2.6 Severity: wishlist Maybe the linux-image packages could install a cron.daily script that compared the currently installed version to /proc/version and sent an e-mail to root in case there's a mismatch, which most likely means that a new kernel exists, but the machine has not been rebooted. Extra bonus for making this debconf configurable. ;) Any reason this couldn't be fully implemented externally to linux-2.6? The parsing code should be static enough to live outside, I would think. -- dann frazier -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540202: include a cron reboot reminder
also sprach dann frazier da...@debian.org [2009.08.06.1853 +0200]: Any reason this couldn't be fully implemented externally to linux-2.6? The parsing code should be static enough to live outside, I would think. No reason why it couldn't happen externally. It just seems that the linux-image packages are the logical place for it. Otoh, if you have multiple images installed, only the one with the highest version should be considered. A better approach would be something like /var/lib/debian/reboot-required.d, where packages can drop files containing reasons why a reboot is needed. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems i dislike arguments of any kind. they are always vulgar, and often convincing. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#540202: include a cron reboot reminder
On Thu, Aug 06, 2009 at 08:35:49PM +0200, martin f krafft wrote: also sprach dann frazier da...@debian.org [2009.08.06.1853 +0200]: Any reason this couldn't be fully implemented externally to linux-2.6? The parsing code should be static enough to live outside, I would think. No reason why it couldn't happen externally. It just seems that the linux-image packages are the logical place for it. To me, it seems more like an external service. Like you mention, multiple linux-image packages could be installed at one time, so it would seem like the logic is something we'd want to factor out into a single standalone package. It is also very difficult to do any amount of rapid development within the linux-2.6 source package as new uploads require a lot of resources. Otoh, if you have multiple images installed, only the one with the highest version should be considered. True - though, theoretically this could be more complex than that. For example, just because 2.6.30 is installed doesn't mean that 2.6.26 isn't still configured to be the default. We could play ignorant and always tell the user that they need to reboot after installing any new kernel, but it would be cool if we could be more intelligent about it. It might make sense to do this as a commandline toolset, and let other people build tools on top as they wish. e.g.: $ kernstatus --booted-kernel UNAME=2.6.26-2-686 PKGVER=2.6.26-18 $ kernstatus --default-kernel UNAME=2.6.30-1-686 PKGVER=2.6.30-5 I could see using such a tool inside of s2disk to make sure that we will be booting the same kernel we used to hibernate. Possibly offtopic, I've also personally always wanted a simple, bootloader/arch independent tool that knows how to list the available kernels, and have the option to set a given kernel as the default for the next boot. e.g.: $ kerntool --list-images 2.6.30-1-686 2.6.26-2-686 $ kerntool --set-default 2.6.30-1-686 A better approach would be something like /var/lib/debian/reboot-required.d, where packages can drop files containing reasons why a reboot is needed. 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. 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. -- dann frazier -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540202: include a cron reboot reminder
also sprach dann frazier da...@debian.org [2009.08.06.2118 +0200]: To me, it seems more like an external service. Like you mention, multiple linux-image packages could be installed at one time, so it would seem like the logic is something we'd want to factor out into a single standalone package. It is also very difficult to do any amount of rapid development within the linux-2.6 source package as new uploads require a lot of resources. Good point. It might make sense to do this as a commandline toolset, and let other people build tools on top as they wish. e.g.: $ kernstatus --booted-kernel UNAME=2.6.26-2-686 PKGVER=2.6.26-18 $ kernstatus --default-kernel UNAME=2.6.30-1-686 PKGVER=2.6.30-5 I could see using such a tool inside of s2disk to make sure that we will be booting the same kernel we used to hibernate. Possibly offtopic, I've also personally always wanted a simple, bootloader/arch independent tool that knows how to list the available kernels, and have the option to set a given kernel as the default for the next boot. e.g.: $ kerntool --list-images 2.6.30-1-686 2.6.26-2-686 $ kerntool --set-default 2.6.30-1-686 This all sounds too nice. Otoh, I am sure grub2 people will play along, and it shoud be trivial to do for grub1 too. A better approach would be something like /var/lib/debian/reboot-required.d, where packages can drop files containing reasons why a reboot is needed. 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. 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! -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems my father, a good man, told me: 'never lose your ignorance; you cannot replace it.' -- erich maria remarque digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#540202: include a cron reboot reminder
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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540202: include a cron reboot reminder
also sprach dann frazier da...@debian.org [2009.08.06.2150 +0200]: 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. Every. single. one. ;) 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). For the running kernel version (2.6.30 is 2.6.30, so 2.6.30-1-amd64 == 2.6.30-2-amd for this purpose), check if there is an image package installed that is strictly larger in version than what's currently running according to /proc/version. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems ... and so he killed Miguel in a rit of fealous jage. -- inspector clouseau digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
