I've did some googling and have not came up with and answer yet. Is there a list of packages that after update require a reboot, other then kernel?
TIA Brian
Brian wrote:
I've did some googling and have not came up with and answer yet. Is there a list of packages that after update require a reboot, other then kernel?
That is a difficult question, and the answer depends on how certain you need to be that no running process is still using the old version. For system daemons, a restart is typically done in the post-install script, provided that can be done non-disruptively. Long-running user processes (shells, browsers, mail readers, etc., etc.) will still be using the old versions of executables, libraries, and other resources until the user terminates the process or logs out. Library updates in particular are a big problem because there is no reliable way to know whether the (now unlinked) old version is still in use. For a lot of files, "lsof | egrep 'DEL|deleted'" will show deleted versions still in use, but libraries in particular are typically mmap()ed and closed, so lsof won't pick them up even though they are still in use.
For updates other than the kernel, there is almost always an answer short of a full reboot. But, finding that answer and being 100% certain that it is a complete answer can be a challenge, and is, say, bringing the system down to single-user mode momentarily all that much better than simply rebooting?
On 1/9/2009 9:49 AM, Robert Nichols wrote:
Brian wrote:
Is there a list of packages that after update require a reboot, other then kernel?
For updates other than the kernel, there is almost always an answer short of a full reboot. But, finding that answer and being 100% certain that it is a complete answer can be a challenge, and is, say, bringing the system down to single-user mode momentarily all that much better than simply rebooting?
If a hard reboot is what you are attempting to avoid, with 'kexec' even the Linux kernel can be "reloaded" without a hardware reset. This is convenient if you want to avoid the long system reset time.
"Kexec is a patch to the Linux kernel that allows you to boot directly to a new kernel from the currently running one. In the boot sequence described above, kexec skips the entire bootloader stage (the first part) and directly jumps into the kernel that we want to boot to. There is no hardware reset, no firmware operation, and no bootloader involved. The weakest link in the boot sequence -- that is, the firmware -- is completely avoided. The big gain from this feature is that system reboots are now extremely fast. For enterprise-class systems, kexec drastically reduces reboot-related system downtime. For kernel and system software developers, kexec helps you quickly reboot your system during development or testing efforts without having to go through the costly firmware stage every time." [1]
Kenneth
[1] http://www.ibm.com/developerworks/linux/library/l-kexec.html
On 1/15/09, Kenneth Burgener kenneth@mail1.ttak.org wrote:
On 1/9/2009 9:49 AM, Robert Nichols wrote: If a hard reboot is what you are attempting to avoid, with 'kexec' even the Linux kernel can be "reloaded" without a hardware reset. This is convenient if you want to avoid the long system reset time.
"Kexec is a patch to the Linux kernel that allows you to boot directly to a new kernel from the currently running one. In the boot sequence described above, kexec skips the entire bootloader stage (the first part) and directly jumps into the kernel that we want to boot to. There is no hardware reset, no firmware operation, and no bootloader involved. The weakest link in the boot sequence -- that is, the firmware -- is completely avoided. The big gain from this feature is that system reboots are now extremely fast. For enterprise-class systems, kexec drastically reduces reboot-related system downtime. For kernel and system software developers, kexec helps you quickly reboot your system during development or testing efforts without having to go through the costly firmware stage every time." [1]
if you really have to have as perfect an uptime as possible then you can actually patch a running kernel using ksplice
should only be used for critical security updates but useful nonetheless
mike
Michael Simpson wrote:
if you really have to have as perfect an uptime as possible then you can actually patch a running kernel using ksplice
should only be used for critical security updates but useful nonetheless
mike _______________________________________________
Its not that I want a perfect uptime, I just want to make sure I reboot when needed and not reboot when it is not necessary.
Thank you all for your input. Brian.
-
Brian -
Kenneth Burgener -
Michael Simpson -
Robert Nichols