Solved Why restart works ? Technical reason ?
-
Technical reason is that reboot clears current state of the software and start from the scratch again. Running software generates junk over time that usually sits in memory, or worse, software suffers from memory leaks, Firefox is a poster child here. Rebooting wipes all that.
And if you want to get really technical, you can even mention cosmic radiation. IBM did a research on that at some point, and they concluded that a PC with 256MB of RAM was going to experience memory errors due to radiation once a month. Bump memory to 8GB and you have one error a day, statistically speaking of course. All that does not apply to ECC memory, but most desktops will not have that.
-
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
-
@openit said in Why restart works ? Technical reason ?:
Yes, so many times it works.
Being a technical guy, I would like to know technical reasoning, to be aware of and answer if any user asks.
Because it takes the system to a known state that, presumably, is how it got working in the first place. Nothing that has changed in memory is retained.
-
@openit said in Why restart works ? Technical reason ?:
On other hand, some times I don't know the reason for some specific issue, user just wonder on those issues and asks why it happened, and I don't have answer, is that normal or happens with you ? if so, is that okay ?
It's more than okay, it is very often important to the business to not expend large resources to find the cause of something when the cause is likely unimportant and the cost of fixing is so high.
-
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
Instead of re-imaging?
-
@scottalanmiller said in Why restart works ? Technical reason ?:
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
Instead of re-imaging?
What is this re-imaging?
That's one my list of stuff to fix: Develop an image, despite most workstations having different software installation needs.
-
@scottalanmiller said in Why restart works ? Technical reason ?:
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
Instead of re-imaging?
I don't jump straight to re-imaging, I'll spend at least 30 mins fixing first.
-
@eddiejennings said in Why restart works ? Technical reason ?:
@scottalanmiller said in Why restart works ? Technical reason ?:
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
Instead of re-imaging?
What is this re-imaging?
That's one my list of stuff to fix: Develop an image, despite most workstations having different software installation needs.
That's what SodiumSuite is designed to fix.
-
@dashrender said in Why restart works ? Technical reason ?:
@scottalanmiller said in Why restart works ? Technical reason ?:
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
Instead of re-imaging?
I don't jump straight to re-imaging, I'll spend at least 30 mins fixing first.
I'd do triage and determine the likelihood of 30 minutes being useful. Because an image process could be under 30 minutes and more reliable, you want to make that call early.
-
@scottalanmiller said in Why restart works ? Technical reason ?:
@dashrender said in Why restart works ? Technical reason ?:
@scottalanmiller said in Why restart works ? Technical reason ?:
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
Instead of re-imaging?
I don't jump straight to re-imaging, I'll spend at least 30 mins fixing first.
I'd do triage and determine the likelihood of 30 minutes being useful. Because an image process could be under 30 minutes and more reliable, you want to make that call early.
Of course.
-
When you deal with third party software, that you dont have alot of documentation and you have to support it, like EMR system, and you really dont want to learn it cause it using old software, for example running on centos 6 so you really dont want to delve in that old stuff, and services load and start but the web app is not showing so you just keep restarting the crap out of it till it works and the hospital can resume activity.
And you have worthless EMR manager, that cannot stand to the developers and tell them fix their shit. cause her experience is diploma degree, but of-course she is an international expat so she gets the job regardless.
-
That's nice information.
-
@scottalanmiller said in Why restart works ? Technical reason ?:
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
Instead of re-imaging?
I just wonder, how we can simply jump to re-imaging or reset or re-installation, unless necessary or investigating the issue, it may repeat if cause is not from that computer...?
-
@openit said in Why restart works ? Technical reason ?:
@scottalanmiller said in Why restart works ? Technical reason ?:
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
Instead of re-imaging?
I just wonder, how we can simply jump to re-imaging or reset or re-installation, unless necessary or investigating the issue, it may repeat if cause is not from that computer...?
It "may" repeat, but the chances are extremely low if you have an issue on one machine. More importantly - investigating causes is extremely expensive and generally worthless (we rarely find something at all, and when we do, it is rarely of value.) That something "may repeat" sounds important, but it makes something trivial sound scary.
In real life, 99%+ of issues that we experience on an end user machine are from the end user machine and can be fixed by starting with a clean copy. A good process for this lowers cost and raises protection as imaging fixes many problems that we might not even have known about. Imaging is a much safer process, investigating leaves us often unsure if we've found "everything" and if we've fully fixed it.
So imaging is often where we almost start, because it is fast, reliable, and cost effective for the business. IT always wants to "know what was wrong", but ask the business if this makes sense. To the company, the right answer is the one that saves money, not the one that gets to the bottom of things.
-
In an ideal world, of course, we'd track down every problem and solve it. This not only means we always know what happened, but we know how to prevent it, in theory.
But the real world doesn't work that way very often. Tracking down a problem is generally time consuming, and unreliable. And finding one problem might hide another. A problem that causes instability might hide one that causes data loss, for example.
Imaging should take around thirty minutes and, in reality, we are often getting that number lower and lower. With a "good" setup, it might easily be only 15-20 minutes. And with VDI you might be looking at mere seconds or at single minute, at most. These numbers are getting really small.
In many cases, an L0 helpdesk tech can have a serious issue resolved via imaging before someone who knows enough to figure out the issue can even respond.
-
Now, of course, if you have loads of IT free time and this kind of investigation becomes the absolute best use of IT's time, then you can consider things like having replacement machines ready to go and swapping, rather than re-imaging, and then you can take the old equipment or snapped VM to a "lab" for investigation while not impacting the business to do so. But, in most cases, this is only available to companies with rather deep pockets as spare gear is rarely cheap.
-
@scottalanmiller said in Why restart works ? Technical reason ?:
In an ideal world, of course, we'd track down every problem and solve it. This not only means we always know what happened, but we know how to prevent it, in theory.
But the real world doesn't work that way very often. Tracking down a problem is generally time consuming, and unreliable. And finding one problem might hide another. A problem that causes instability might hide one that causes data loss, for example.
Imaging should take around thirty minutes and, in reality, we are often getting that number lower and lower. With a "good" setup, it might easily be only 15-20 minutes. And with VDI you might be looking at mere seconds or at single minute, at most. These numbers are getting really small.
In many cases, an L0 helpdesk tech can have a serious issue resolved via imaging before someone who knows enough to figure out the issue can even respond.
Now granted itβs not Windows but we can rekickstart in about 10-15 mins.
-
@stacksofplates said in Why restart works ? Technical reason ?:
@scottalanmiller said in Why restart works ? Technical reason ?:
In an ideal world, of course, we'd track down every problem and solve it. This not only means we always know what happened, but we know how to prevent it, in theory.
But the real world doesn't work that way very often. Tracking down a problem is generally time consuming, and unreliable. And finding one problem might hide another. A problem that causes instability might hide one that causes data loss, for example.
Imaging should take around thirty minutes and, in reality, we are often getting that number lower and lower. With a "good" setup, it might easily be only 15-20 minutes. And with VDI you might be looking at mere seconds or at single minute, at most. These numbers are getting really small.
In many cases, an L0 helpdesk tech can have a serious issue resolved via imaging before someone who knows enough to figure out the issue can even respond.
Now granted itβs not Windows but we can rekickstart in about 10-15 mins.
Well, and kickstarting is not really all that fast. Full on imaging can be even faster.
-
@eddiejennings said in Why restart works ? Technical reason ?:
I'll often have users do a restart, but if the issue is recurring, then I'll take the time to try to find the root cause.
We do a minimum of forced weekly reboot of computers with updates, regardless of whether or not updates are installed.
It's been helping a LOT, and is a free way to fix or prevent many issues that waste time and effort from nobody rebooting.
-
Another thing to consider is whether this is a workload you are managing as a service, or whether you are providing support to an end user using an endpoint to access services that you support. If it is an end user, the quickest route to addressing the problem is frequently having them reboot. There are usually far too many variables, that directly correlate to the other human in the equation, to afford a reasonable amount of time to adequately diagnose the root cause of the problem(s) they are experiencing.
However, if you are managing a service it is probably better to take a bit of time beforehand and set up proactive monitoring that will provide metrics that can be used to establish baseline patterns and trends that can in turn be observed and used to identify deviations that lead to undesirable application and system states. This will allow you to detect anomalous states and enable auto-healing features that will automatically remedy issues before they get to the point that a reboot is the necessary remediation.
If you are managing immutable/stateless workloads (containers/microservices) that use a service oriented architecture, this is much easier to implement and manage. If you're dealing with traditional monolithic applications it can up the difficulty of implementation by quite a bit.