On 2/22/2016 8:14 AM, rbowman wrote:
On 02/21/2016 10:50 PM, Don Y wrote:
I'm surprised MS hasn't scheduled a cron job to automatically initiate
reboots -- rather than FIX leaks! :

They've come close. The default for Server 2008 was to download and apply
patches automatically.

Yeah, but the reboot(s) are to apply the patches. Imagine if they simply
forced a reboot to ensure everything was starting from a "known state"?
(Don't worry about memory leaks or data corruption; just reboot often
enough that the consequences never manifest!)

One strategy for high reliability devices is to deliberately reboot
them so they are in a known state. I.e., instead of a big loop,
just let it run one iteration and arrange for HARDWARE to kick the
reset at about the same time. Note that this differs from a watchdog
which is NEVER intended to trip -- doing so is a sign of a failure!

But, you don't do this (regular resets) to HIDE flaws but, rather,
prevent anomalous conditions from hanging your product (e.g.,
a bit getting flipped in some flag that controls your code/loop)

The people in a 911 dispatch center get a little testy
when the server reboots in the middle of calls. It's easy enough to change the
setting but that means the server never gets the updates until you absolutely
have to reboot and then there can be a hundred or so.

Yup. So, you defer the updates -- which means the problem gets bigger
as well as the cost of the eventual "fix"... which means you postpone it
still more...

Windows was never meant for the five nines world.

It's hard making things that "just (continuously) run". My automation system
is never intended to see a reboot. So, how do you introduce updates?
Major configuration changes? New hardware? You have to address these
possibilities in the initial design -- you can't "retrofit" them!