I've also read that NT 4 servers on AEGIS cruisers once had to be rebooted weekly.
This bug took down air traffic control computers: http://news.techworld.com/operating-systems/2275/microsoft-s...
That's not so bad. So long as they have the option to skip this week's reboot, this shouldn't be a problem in combat. (They should've randomized the reboot schedule so that an enemy couldn't exploit it.)
It seems you could get close to ensuring such a time would exist by creating constant emergencies for the crew to deal with such that rebooting would be hazardous, and waiting for the reboot-or-crash date to launch the major attack.
Sun Microsystems Inc. SunOS 5.8 Generic February 2000
DST Patches Applied Tue Mar 6 17:16:02 CST 2007
# uname -a
SunOS 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-60
# uptime
3:36pm up 811 day(s), 17 min(s), 3 users, load average: 0.63, 0.79, 0.74
It's happened to me before.
Go reboot that damn thing!
He's saying, how do you know that the system hasn't acquired some sort of configuration/software/hardware degradation in the meantime that only manifests on boot?
If you don't regularly exercise/test a critical function, then you substantially increase your risk that the critical function will fail when you really do need it.
Q: What's the worst time to find out your system won't boot? A: Right after it crashed.
You are better off with scheduled maintenance periods where you can reboot the server and it isn't critical if it fails. That gives you a chance to correct anything on your terms rather than fire-fighting.