Many years ago, during the Win95/98 era, there was a war between Linux and Win users over which OS had the longest uptime. The SuSE 6.4 server in my office, running a PostgreSQL server, had been up over 400 days. Win users were claiming uptimes of over 600 days! Then, at the peak of the war, Microsoft announced the 32bit clock bug which automatically rebooted any Win95 machine after 49.7 days. A LOT of Win users were caught with egg on their face.
Those wars are long gone, and so is the philosophy that the hardest thing you can do to a machine is turn it on or turn it off. In the early days of desktop most failures happened during the surge of current and the spikes of voltage that occurred during those two events. Leaving a machine up and running was the best solution, and it required a very stable OS. Typical desktops had 500 watt power supplies and 120 to 240 watts of monitor, plus standby power supplies, printers and other current hungry devices. Leaving them up 24/7/365 could add a bit to one's power bill.
Times have changed. Laptops and netbooks are constantly turned on and off with no harm, and they usually sip less than 20 watts of power, some much less. There is little reason, unless critical applications require it (Internet server, home security system...etc.) to leave laptops on for extended lengths of time.
BUT (you knew there'd be a "but" in this, didn't you?), my KWheezy is running so fine I decided to see how stable it really was. So far, it has been running 18 days 3 hours and 7 minutes without a reboot or a hiccup. Long enough that if anything were to go wrong it would have by now. Besides, the MTBF clock of my HD, and other components, pay the price for long uptimes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's a funny story. Perhaps those win users patched the 32bit clock bug themselves. Wait a minute, they can't, coz they don't have access to the code.
400 days! Nice one mate. I've looked after servers for about 15 years now and I've never managed more than a year. Not so much because of kernel panics or services not restarting. But because of power outages, kernel updates and generally wanting to be on new stuff all the time. I'd like to look after something mission critical one day, so that I won't be tempted to tinker.
Well it's true that uptime on a desktop is overated. But It's good to not have to reboot because something starts behaving strange. On servers however, monitoring uptime is kind of fun. Only it causes unecessary disapointment when you need to do a planned reboot, when nothing was wrong with the server. Or when power outage is longer than UPS can supply.
My colleague told me story about one of his previous work-places. The guy in charge of a Solaris server had an uptime of 5 years or more. Then a junior admin staff experienced a badly behaving service when this guy was not around. Not knowing what to do to fix it, he rebooted the server. When the guy found out about it, and knowing it could have been fixed by restarting the service. Can you imagine how angry he was. I know how I would have felt.
Last edit: Euan Thoms 2014-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many years ago, during the Win95/98 era, there was a war between Linux and Win users over which OS had the longest uptime. The SuSE 6.4 server in my office, running a PostgreSQL server, had been up over 400 days. Win users were claiming uptimes of over 600 days! Then, at the peak of the war, Microsoft announced the 32bit clock bug which automatically rebooted any Win95 machine after 49.7 days. A LOT of Win users were caught with egg on their face.
Those wars are long gone, and so is the philosophy that the hardest thing you can do to a machine is turn it on or turn it off. In the early days of desktop most failures happened during the surge of current and the spikes of voltage that occurred during those two events. Leaving a machine up and running was the best solution, and it required a very stable OS. Typical desktops had 500 watt power supplies and 120 to 240 watts of monitor, plus standby power supplies, printers and other current hungry devices. Leaving them up 24/7/365 could add a bit to one's power bill.
Times have changed. Laptops and netbooks are constantly turned on and off with no harm, and they usually sip less than 20 watts of power, some much less. There is little reason, unless critical applications require it (Internet server, home security system...etc.) to leave laptops on for extended lengths of time.
BUT (you knew there'd be a "but" in this, didn't you?), my KWheezy is running so fine I decided to see how stable it really was. So far, it has been running 18 days 3 hours and 7 minutes without a reboot or a hiccup. Long enough that if anything were to go wrong it would have by now. Besides, the MTBF clock of my HD, and other components, pay the price for long uptimes.
That's a funny story. Perhaps those win users patched the 32bit clock bug themselves. Wait a minute, they can't, coz they don't have access to the code.
400 days! Nice one mate. I've looked after servers for about 15 years now and I've never managed more than a year. Not so much because of kernel panics or services not restarting. But because of power outages, kernel updates and generally wanting to be on new stuff all the time. I'd like to look after something mission critical one day, so that I won't be tempted to tinker.
Well it's true that uptime on a desktop is overated. But It's good to not have to reboot because something starts behaving strange. On servers however, monitoring uptime is kind of fun. Only it causes unecessary disapointment when you need to do a planned reboot, when nothing was wrong with the server. Or when power outage is longer than UPS can supply.
My colleague told me story about one of his previous work-places. The guy in charge of a Solaris server had an uptime of 5 years or more. Then a junior admin staff experienced a badly behaving service when this guy was not around. Not knowing what to do to fix it, he rebooted the server. When the guy found out about it, and knowing it could have been fixed by restarting the service. Can you imagine how angry he was. I know how I would have felt.
Last edit: Euan Thoms 2014-01-21