3 ms·

Now this is an excellent reason and timeframe for doing periodic reboots. It's basically a scheduled sanity check for your infrastructure. It boils down to rob

by mpk 16y ago

Now this is an excellent reason and timeframe for doing periodic reboots. It's basically a scheduled sanity check for your infrastructure. It boils down to robustness and assurance. If parts of your system won't survive a reboot this is an unknown and therefore a risk. If a system can't survive a reboot it's better to find that out when it's during a scheduled reboot and personnel is on hand to deal with it rather than relying on on-call personnel responding to alarms from monitoring at some point. Apart from the repair time being longer when relying on on-call technicians, there is also the general observation that productive systems tend to become more valuable or have more exposure over time as their usage increases. A failure at a later point therefore also becomes more costly as time goes by.

rbanffy 16y ago
> Now this is an excellent reason and timeframe for doing periodic reboots. Most of the time you don't need to do complete reboots. Restarting services usually takes care of the majority of the sanity checks.
- mpk 16y ago
  > Restarting services usually takes care of the majority of the sanity checks. Sure, that usually takes care of most checks, but the point is to eliminate as much as possible unusual scenarios. A service-level restart will catch service config mismatches, but it won't catch, for example, manual interface or routing table updates. It also won't catch the 'fragile root' problem where the device that the kernel is loaded from has become corrupt. Bad things happen in the strangest places if you run enough systems.
  - rbanffy 16y ago
    True. You still would need to reboot from time to time, it's just that you can restart services much more frequently, even automatically if your humans know what is going down today and what can they expect if things go wrong. But I agree - the objective is to detect those situations when things have gone wrong a long time ago and we just don't know it yet. ;-)

by mpk 16y ago

rbanffy 16y ago

> Now this is an excellent reason and timeframe for doing periodic reboots. Most of the time you don't need to do complete reboots. Restarting services usually takes care of the majority of the sanity checks.

mpk 16y ago
> Restarting services usually takes care of the majority of the sanity checks. Sure, that usually takes care of most checks, but the point is to eliminate as much as possible unusual scenarios. A service-level restart will catch service config mismatches, but it won't catch, for example, manual interface or routing table updates. It also won't catch the 'fragile root' problem where the device that the kernel is loaded from has become corrupt. Bad things happen in the strangest places if you run enough systems.
- rbanffy 16y ago
  True. You still would need to reboot from time to time, it's just that you can restart services much more frequently, even automatically if your humans know what is going down today and what can they expect if things go wrong. But I agree - the objective is to detect those situations when things have gone wrong a long time ago and we just don't know it yet. ;-)