What exactly does rebooting accomplish?

Rebooting is frequently a first-step approach to solving all sorts of technical issues, for a variety of devices. How exactly does this work?

In the case of computer and phones, I imagine it’s possible that the problem arose from the interaction of various programs/apps which were running, and that if you start up again you might run different programs (or in a different sequence, or different start-up programs) which could help things. But what about things like routers? What would be different the second time around than the first time?

Routers also have internal states that change over time. Exactly which states cause issues I do not know, but if the people who write router software/firmware actually knew you’d think they’d would have fixed it by now.

Computers have a number of finite resources, mainly memory, but also network sockets, file handles, semaphores and others. Ill-behaved programs can claim some of these resources and never give them back. Rebooting clears the deck. It’s a difficult problem, but good operating systems can rein in some of these issues. That’s why Windows boxes, especially the older versions, need to be rebooted more often.

This is exactly it. Over time, computer systems can get into a broken internal state. Sometimes the state is only a little broken and some part doesn’t work well or reliably. Sometimes it’s completely broken. Rebooting resets things to a known consistent state (that was probably well tested) so things are more likely to work (for a while at least).

As I mentioned in another thread, once my printer gives an out of paper message, refilling the paper tray does not fix. Refilling the paper and rebooting does. It reinitializes everything.

Always reboot 3 times. (whole video click here to jump ahead a little)

Pretty much everything these days is really a tiny computer under the hood. Most are pretty highly customized/optimized to do their specific jobs, but they’re still operating systems with internal states and memory and what-not that can get out of whack.

Rebooting resets all that- you’re essentially starting with a clean slate. A half-assed apology might be that if you’re trying to keep a list of stuff on paper with a pencil, eventually you’ll get to the point where your new writing is hard to read, it’s hard to write, your pencil gets dull, etc… Sharpening your pencil and getting a clean sheet of paper is the equivalent of a reboot in this case.

Half-assed? That’s barely any apology at all!

Crud! Auto-correct. I meant “Analogy”.

It’s different because things don’t happen in the exactly the same way each time. The particular pattern of packets and timing which messed up the router the first time probably won’t happen exactly the same way the next time. But the router may still mess up again in the future because the core issue which caused the problem may happen again. For example, if the router gets overwhelmed with the traffic and drops packets, the internal count may get messed up and the router may not have the right error checking in place to detect the problem. Then once again you notice the wifi or something isn’t working and rebooting resets everything back to zero.

I design electronic hardware that needs to run un-attended indefinitely. So, reliability is extremely important. One product I designed had some subtle bug that would cause it to stop working after several months of operation. After spending way too much time hunting (unsuccessfully) for the bug, I eventually gave up and just wrote the firmware so that it re-booted itself periodically. Since doing this, we have had no more bug reports…

As already stated, rebooting clears all temporary state and gives programs a chance to start anew, hopefully for the better.

Computer programs are complex. Any non trivial program has an exponentially large number of possible states. Programs are tested before being released, but there is just no way that all possible states can be tested, so every program has an exponential number of possible states that are potentially problematic.

Programs are built using libraries, which have the same underlying complexity and potential for bugs.

Libraries call lower level libraries and eventually libraries exposed by the operating system interface. The operating system is itself a collection of programs, each of them dedicated to operate a different piece of hardware (device or chip).

Every device or chip is in itself a little computer and has its own stack of programs, the firmware of the device.

it is programs all the way down, and at each step only a small subset of possible states is tested. And each little piece is developed by and large in isolation from the other ones.

Now, imagine that on an average computer you have at least a few hundred programs (processes) running at once. On a simpler device, you may have fewer, but still the vastness of the state space is mind boggling.

When you think about it, it’s a tribute to human ingenuity that we can get anything done at all between a reboot and the next one.

I suspect that the number one cause is memory leaks, where a program allocates memory and never frees it. Shoddy programming, it can be found if you look for it, but not a bug that would show up in testing for software where schedule is king.
There are other reasons. The processor I worked on had a subtle bug that sometimes randomly raised an error flag, causing a reboot. I could see the service records for the processor, and found a case where it caused a reboot and then didn’t fail again for a year.
Programs failing in weird ways might be a cause also.
Computers aren’t the only thing rebooted these days. Around 15 years ago the TV set in a hotel I was staying at had to be rebooted. I wrote a column about it, and someone told me that her digital picture frame frequently had to be rebooted. My DVR does fairly often, and my new smart TV gets into funny states some times.

Re: Always reboot 3 times


There’s also the running gag: IT Crowd - Have You Tried Turning It Off And On Again? - YouTube

The most reliable way to reboot is turn the device off and then back on. A reboot or reset action doesn’t necessarily totally clear the memory and initial states of all components in the device. It’s supposed to restart everything in the initial state, but some components may retain their previous state even after a soft reboot. Turning the device off and on is the most reliable way to ensure things are put back in the initial state.

I still count to ten before turning back on. It’s force of habit from the days when DRAM refresh times were long enough that a second or two without power wasn’t necessarily enough to completely zero out memory.

I never worked with magnetic-core memory, where power wasn’t necessary to maintain its contents.

This is probably about as good a simple explanation as the OP is going to get. It is indeed a difficult and complex problem. Old versions of Windows needed to be rebooted fairly often just because they’d become unstable or crashed. Newer versions – basically since the transition to the NT kernel in Windows XP – have been much more stable.

But a simple way of looking at it is this. If you freshly boot a system, it will have a clean initial state; call it Si. Now if you run programs A, B, and C, and then shut them down, you might naively think that your system will be back to Si. Ha ha! Not even close! Not even if A, B, and C have (apparently) done nothing at all except start and exit. The system will now be in a new state S2, which will be substantially different than Si. The amount of cached, available, and free memory will likely be different, the amount of nonpaged pool will likely be higher – if not, trust me, it will become higher over time, and never go down (nonpaged memory is the amount of permanently resident memory allocated to the OS); the count of process handles and threads may well be different. Certainly, the internal in-memory structures will be different, and the general tendency is for them to gradually proliferate and become disordered, a sort of digital entropy.

Furthemore, rebooting will create a new initial state Si2, which will probably be very similar and likely functionally the same as the previous Si, but almost certainly not identical. That’s because there is such an enormous number of processes that interact in complex ways at system startup that timing differences tend to yield subtly different results, and in marginal cases that’s why on some startups some applications come up correctly and sometimes not. This is why some people believe computers are the spawn of Satan. :wink: The actual reality is that modern hardware and software systems involve very, very complex interactions in which timing plays an important role. It’s actually amazing – and a credit to robust engineering and disciplined modularity – that it usually works as well as it does.

There are also a lot of programs running that don’t necessarily interact well with each other.
Back when software came on CDs I heard a talk from a system test guy at Dell. He said that the reason they preloaded all the software they shipped with was not for the convenience of the user, but because given the millions of potential configurations of hardware and software the only way to kind of ensure the system was going to work was to load it and try it out before it shipped. And things were easier back then.

As do I, not with PCs but with other devices. I do this to give time for capacitors to clear. Like a monitor, switch, printer, etc.

I do this a lot too since I do IT support for a living. I’m sure it’s not always necessary but it’s just 10 seconds.

I would say “turn it off and on again” is usually just one of the steps in fixing an issue.
About the only things it solves in itself is poor performance due to high memory use and programs that can’t be terminated because of file handles they’re holding or whatever.

The rest of the time it’s more that fixing an issue may require installing or uninstalling software or device drivers. In which case a reboot may be necessary as the operating system needs to allocate certain resources or permissions during the startup sequence (allowing some of these things to change while they are in use would itself cause problems).
This might not be so obvious to the end user though, as, for example, in a corporate environment an install or update may have been rolled out via the network, but may not function correctly until you restart.

Or it’s necessary to diagnose startup problems, which will involve rebooting into some kind of diagnostic mode. Maybe even into the BIOS.