IT Support
Our IT support guy has been in the job since 1979, and never misses an opportunity to pick up a mouse and say "Hello computer" into it, Star Trek-style. Tell us your tales from the IT support cupboard, either from within or without.
( , Thu 24 Sep 2009, 12:45)
Our IT support guy has been in the job since 1979, and never misses an opportunity to pick up a mouse and say "Hello computer" into it, Star Trek-style. Tell us your tales from the IT support cupboard, either from within or without.
( , Thu 24 Sep 2009, 12:45)
« Go Back
Switching it off and on again
is never a proper solution. It doesn't stop the problem happening again. It's something only lazy fuckers (i.e. IT people) suggest.
( , Mon 28 Sep 2009, 13:39, 23 replies)
is never a proper solution. It doesn't stop the problem happening again. It's something only lazy fuckers (i.e. IT people) suggest.
( , Mon 28 Sep 2009, 13:39, 23 replies)
Go
fuck yourself.
Turning it off then turning it on again isn't something IT people suggest, it's something helldesk people suggest.
( , Mon 28 Sep 2009, 13:43, closed)
fuck yourself.
Turning it off then turning it on again isn't something IT people suggest, it's something helldesk people suggest.
( , Mon 28 Sep 2009, 13:43, closed)
Agreed
However, working in firstline, you'd be surprised the number of times it works and the problem doesn't re-occur.
( , Mon 28 Sep 2009, 13:49, closed)
However, working in firstline, you'd be surprised the number of times it works and the problem doesn't re-occur.
( , Mon 28 Sep 2009, 13:49, closed)
not entirely true
Windows (non-server versions, obviously) itself isn't intended to be a 24/7 server. Furthermore, anyone can write programs, with little or no quality control - lazy/poor coding leads to memory leaks, which can lead to system resources being entirely consumed and rendered unfreeable.
You could recode the program, I suppose - that would be the proactive and responsible thing to do - or you could accept the fact that we live in an imperfect world, and just reboot the fucking machine.
( , Mon 28 Sep 2009, 13:50, closed)
Windows (non-server versions, obviously) itself isn't intended to be a 24/7 server. Furthermore, anyone can write programs, with little or no quality control - lazy/poor coding leads to memory leaks, which can lead to system resources being entirely consumed and rendered unfreeable.
You could recode the program, I suppose - that would be the proactive and responsible thing to do - or you could accept the fact that we live in an imperfect world, and just reboot the fucking machine.
( , Mon 28 Sep 2009, 13:50, closed)
Works, plural.
Meaning you have had to do it more than once. Meaning that it didn't fix the problem the first time.
( , Mon 28 Sep 2009, 15:08, closed)
Meaning you have had to do it more than once. Meaning that it didn't fix the problem the first time.
( , Mon 28 Sep 2009, 15:08, closed)
That would be 'worked', 'will work' or 'is working' if it were singular.
'Works' is plural. "The soluton" may be singular, but "works" suggests that the solution is used multiple times.
( , Tue 29 Sep 2009, 14:58, closed)
'Works' is plural. "The soluton" may be singular, but "works" suggests that the solution is used multiple times.
( , Tue 29 Sep 2009, 14:58, closed)
well...
If you've decided to open up a load of different ad-riddled freeware, and about 30 different large office documents all open at once building up over the last week, then it can well be the answer.
( , Mon 28 Sep 2009, 13:55, closed)
If you've decided to open up a load of different ad-riddled freeware, and about 30 different large office documents all open at once building up over the last week, then it can well be the answer.
( , Mon 28 Sep 2009, 13:55, closed)
oh, and...
It also helps establish the 'can it be replicated?' bit of trouble shooting. Because if it can't be replicated on that machine, it's going to be a pain in the arse to track down anyway.
( , Mon 28 Sep 2009, 13:56, closed)
It also helps establish the 'can it be replicated?' bit of trouble shooting. Because if it can't be replicated on that machine, it's going to be a pain in the arse to track down anyway.
( , Mon 28 Sep 2009, 13:56, closed)
high speed re-boot
we tune the living bejasus out of common rail diesel engines at work and now and again one will default to limp home mode usually due to overboost on the turbo, to get back to the workshop we reboot by turning off and on again (have done this at high speed on dual carriage way just watch the steering lock!)but to find the problem we have to stall the engine to keep the ecu live. What I am trying to say is that a reboot will hide the problem not fix it and get you back before the coffee is cold
( , Mon 28 Sep 2009, 20:15, closed)
we tune the living bejasus out of common rail diesel engines at work and now and again one will default to limp home mode usually due to overboost on the turbo, to get back to the workshop we reboot by turning off and on again (have done this at high speed on dual carriage way just watch the steering lock!)but to find the problem we have to stall the engine to keep the ecu live. What I am trying to say is that a reboot will hide the problem not fix it and get you back before the coffee is cold
( , Mon 28 Sep 2009, 20:15, closed)
!!
it fixes 99% of the time, doesn't it? what u complaining about? it's all those toolbars you will have installed to tell you the weather in Venezuala or how your shares in 'Ovaltine' are doing...
( , Mon 28 Sep 2009, 13:58, closed)
it fixes 99% of the time, doesn't it? what u complaining about? it's all those toolbars you will have installed to tell you the weather in Venezuala or how your shares in 'Ovaltine' are doing...
( , Mon 28 Sep 2009, 13:58, closed)
See Johnner's post above for an explanation of why it doesn't ever fix the problem
and merely treats the symptoms of the problem. Powering off and on again is like trying to treat cancer by just giving the patient a load of painkillers and weed.
( , Tue 29 Sep 2009, 15:04, closed)
and merely treats the symptoms of the problem. Powering off and on again is like trying to treat cancer by just giving the patient a load of painkillers and weed.
( , Tue 29 Sep 2009, 15:04, closed)
I wonder how many of the respondees knew that it was baiting
and yet couldn't resist anyway
( , Mon 28 Sep 2009, 15:17, closed)
and yet couldn't resist anyway
( , Mon 28 Sep 2009, 15:17, closed)
To be fair, I didn't expect such depth of feeling on the matter.
( , Tue 29 Sep 2009, 14:59, closed)
( , Tue 29 Sep 2009, 14:59, closed)
Hah, "Switch it off and on again" it's the mantra of the Windows Infidel
Followers of the true faith of Unix, know that the path of the infidel is littered with memory leaks, bloatware and regular reboots.
Join the Unix Jihadi and together we will defeat them in this holy OS war.
Alternatively, join us and together we can smack the smug smile off the faces of the MainFrame Sys Progs. Splitters!
( , Mon 28 Sep 2009, 15:32, closed)
Followers of the true faith of Unix, know that the path of the infidel is littered with memory leaks, bloatware and regular reboots.
Join the Unix Jihadi and together we will defeat them in this holy OS war.
Alternatively, join us and together we can smack the smug smile off the faces of the MainFrame Sys Progs. Splitters!
( , Mon 28 Sep 2009, 15:32, closed)
An old story pulled from "The Hacker's Dictionary".
A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Knight turned the machine off and on.
The machine worked.
( , Mon 28 Sep 2009, 15:45, closed)
A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Knight turned the machine off and on.
The machine worked.
( , Mon 28 Sep 2009, 15:45, closed)
I agree. It's not a proper solution.
However, unless you can provide me with the source code to everything running on the computer at any given moment, and the means of finding the bugs and fixing them, it's the best solution you're going to get.
( , Tue 29 Sep 2009, 1:21, closed)
However, unless you can provide me with the source code to everything running on the computer at any given moment, and the means of finding the bugs and fixing them, it's the best solution you're going to get.
( , Tue 29 Sep 2009, 1:21, closed)
'It's a shit solution but it's the best I've got'
That explanation I will accept.
( , Tue 29 Sep 2009, 15:00, closed)
That explanation I will accept.
( , Tue 29 Sep 2009, 15:00, closed)
hmm, i seem to have popped my ITIL hat on :)
Arguably in any service desk scenario, incident and problem management are two seperate processes each with their own priorities. The priorities of the incident management are to restore service to the end user as quickly as possible, and the priority of the problem management process is to focus on gaining understanding of any particular IT failure.
Turn it off and on again is acceptable incident management, however it doesn't satisfy any problem management requirements. Strong problem management is required to prevent the powercycle becoming a default solution.
The OP seems to be arguing for stronger problem management and less "quick fixes", which is a perfectly valid goal when aiming for less overall downtime :).
( , Wed 30 Sep 2009, 12:09, closed)
Arguably in any service desk scenario, incident and problem management are two seperate processes each with their own priorities. The priorities of the incident management are to restore service to the end user as quickly as possible, and the priority of the problem management process is to focus on gaining understanding of any particular IT failure.
Turn it off and on again is acceptable incident management, however it doesn't satisfy any problem management requirements. Strong problem management is required to prevent the powercycle becoming a default solution.
The OP seems to be arguing for stronger problem management and less "quick fixes", which is a perfectly valid goal when aiming for less overall downtime :).
( , Wed 30 Sep 2009, 12:09, closed)
Whilst I agree it's not ideal...
... it's the most practical answer to a lot of problems. It takes a maximum of 10 minutes to reboot (worst case scenario with lots of tray icon crap) - any longer definitely warrants investigation - and when it comes to random little problems it solves them 99% of the time.
As someone earlier said, without knowing the source code to every application and driver, how are we supposed to know why it did the random thing that it did? Whilst it's friendly and reassuring to run straight to their desk with a concerned expression on your face and hold the user's hand, ultimately all you can do is spend *more* than 10 minutes going "hmm. Mmm. Oh dear. Mmm" - and then reboot it for them. Sometimes we're too busy with other things!
(There are exceptions, like if they can't save or something and would lose a day's work)
That said, what I don't do is tell people to reboot if they have the same problem on any kind of even semi regular basis. I say "rebooting it will probably cure the problem, but if it happens again let me know and we'll investigate further". As if it happens more than once or twice, it's then a significant nuisance and stopping them from doing their work, and warrants the extra time spent analysing logs / running scans / rebuilding etc.
( , Wed 30 Sep 2009, 13:21, closed)
... it's the most practical answer to a lot of problems. It takes a maximum of 10 minutes to reboot (worst case scenario with lots of tray icon crap) - any longer definitely warrants investigation - and when it comes to random little problems it solves them 99% of the time.
As someone earlier said, without knowing the source code to every application and driver, how are we supposed to know why it did the random thing that it did? Whilst it's friendly and reassuring to run straight to their desk with a concerned expression on your face and hold the user's hand, ultimately all you can do is spend *more* than 10 minutes going "hmm. Mmm. Oh dear. Mmm" - and then reboot it for them. Sometimes we're too busy with other things!
(There are exceptions, like if they can't save or something and would lose a day's work)
That said, what I don't do is tell people to reboot if they have the same problem on any kind of even semi regular basis. I say "rebooting it will probably cure the problem, but if it happens again let me know and we'll investigate further". As if it happens more than once or twice, it's then a significant nuisance and stopping them from doing their work, and warrants the extra time spent analysing logs / running scans / rebuilding etc.
( , Wed 30 Sep 2009, 13:21, closed)
« Go Back