In <4a4521b9.60...@gmail.com>, AG wrote: >I'm running Squeeze on a desktop and so far have an uptime of some 11d. >I am just curious whether or not there is any guidance/ advice on how >long uptimes should be allowed to be run, or whether it is wise to shut >down and reboot?
Reboots are only needed for a couple of things: 1. Hardware replacement. 2. Kernel replacement. As for 1, the PC architecture isn't quite up to the standards of "Big Iron" so if you are adding/removing/replacing RAM/CPU/boards you'll need to shut the system down for that. As for 2, any time a new security update of your kernel is released you should stop using your existing kernel and start using the new kernel. This can be done with the kexec() syscall, which will preserve your uptime, but not all kernels have the kexec() syscall. Now, there are some fairly fundamental services that are difficult to cleanly restart. If there's a security update to one of those, it may be easier for you to reboot depending on your skill and time. Take the easy way out, even if the reboot isn't strictly needed. Finally, it is not a bad idea to reboot your systems to make *sure* they will reboot cleanly in the case of (e.g.) power failure. Doing this on some arbitrary schedule doesn't seem incredibly useful, but your administrators should have some sense of "I've changed something about the boot process that can only be tested by actually booting the system". They should schedule a reboot for the next opportunity. Using some sort of H-A clustering can prevent these reboots from affecting your service uptime, even if the kernels uptimes never grow much beyond 90 days. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
