Support tech caught by 'Technician Aura': the bug that only hides when you're watching
- Reference: 1776410947
- News link: https://www.theregister.co.uk/2026/04/17/on_call/
- Source link:
This week, meet a reader we’ll Regomize as “Benny” who in the 1990s worked for a large Australian telco and was sent to fix a recurring problem at a gardening shop – the sort of big box store that sells plants by the acre, and tools by the wheelbarrow-load.
This shop’s point of sale card reading terminals were failing several times a day and Benny was sent to investigate.
[1]
"They had a master terminal that had a line back to a Honeywell DPS6 at one of the local exchanges, and the other terminals were connected to the master terminal on an RS485 bus," he explained.
[2]
[3]
"We had switched to the backup modem at the exchange, run extended Bit Error rate tests on the line, replaced the master terminal, tested the RS485 cabling, and couldn't find anything wrong."
Benny therefore set up a protocol analyser on the RS485 bus and even rustled up a couple of differential probes he hooked up to an oscilloscope "to have a look at the data and clock lines."
[4]
With that rig in place, Benny settled in to watch the systems in the hope of spotting a bug.
"I sat there most of a day waiting for it to crash and of course it didn’t skip a beat," Benny told On Call.
He decided this was a classic case of "Technician Aura," the weird cosmic force that means bugs disappear when a tech support person arrives to fix them. Eventually he gave up trying to find the problem and started writing up a report about the mess.
[5]Tech support chap's boss got him out of jail so he could finish a job
[6]Contractor quaffed his way through Y2K compliance while the client scowled
[7]Engineer sabotaged hardware then complained when it didn't work
[8]While you're here, could you go out of your way to do an impossible job?
As Benny picked up his pen, a colleague arrived to ask how the job was going and put his GSM phone next to the master terminal.
As the two bantered, the phone rang – and staff at the shop immediately complained of a crash.
[9]
"It turned out that the cashier usually placed her phone on the shelf next to the payment terminal," Benny explained. "When I hooked up my monitoring gear, she was forced to relocate to another cash register. When she worked at her usual station, whenever her phone rang, it caused enough interference to crash the payment system."
Have you suffered from "Technician Aura"? If so, try to suppress it long enough to [10]click here and send On Call an email. The mailbag could use a little plumping at the moment, so don’t be shy! ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aeIEyIhH16w0eRv6PryTFQAAAwM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aeIEyIhH16w0eRv6PryTFQAAAwM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aeIEyIhH16w0eRv6PryTFQAAAwM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aeIEyIhH16w0eRv6PryTFQAAAwM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2026/04/10/on_call/
[6] https://www.theregister.com/2026/04/03/on_call/
[7] https://www.theregister.com/2026/03/27/on_call/
[8] https://www.theregister.com/2026/03/20/on_call/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aeIEyIhH16w0eRv6PryTFQAAAwM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] mailto:oncall@theregister.com
[11] https://whitepapers.theregister.com/
It does ring a bell
I'm sorry. couldn't resist. I'll let myself out
I've seen this a few times - the old phones used to cause enough odd problems that they were banned from being in machine rooms. We had to leave them outside and rely on a landline.
I've also seen the opposite effect - everything seeming to be working perfectly until you go to demonstrate it to someone only for it to fail in a way you've never seen before.
Absolutely that.
I'm sure there will be scores of people here who will be able to to post stories about how their code was perfectly fine and functional right up to the point when it was time to demonstrate it to the customer.
I've had it happen to me a number of times.
My first job in IT was in QA. The second product I worked on was the project from hell, but sales kept on pushing the unfinished and very unstable software. As a tester I knew how to make it crash very well, so sales had me design a demo that would actually complete that they could show to customers...
Ah, the practical version of the old compuserve NT forum statement: Never trust benchmark you didn't rig yourself.
:)
"....could show to customers...."
"....could show to customers...."
As a vacation student I was testing a complex semiconductor being driven by standard 74-series TTL. The resulting drive waveforms did not look very square due to the complex load on the electrode. I built a lumped component circuit as a dummy load out of resistors and capacitors for comparison (before SPICE etc was available). The waveforms looked a lot cleaner. My manager suggested that these latter traces should be saved for the data sheet....... I was not around long enough to know if that was ever the case.
On a totally unrelated note, I've learned to never demo anything that has any form of calendar within range of a DST transition.
Definitely test it at that time, but don't try to demo.
We had a similar one way back on a small warehouse unit setup using ACT Apricot's networking. Everyone was convinced it was a power issue so Apricot provided a mains power monitor on loan. Inevitably for the month it was in place there were no network issues, once it had gone back they resumed. The problem was never actually fixed, it just settled down to a manageable level, but there was a slight suspicion that the power monitor had provided some degree of conditioning.
These days we'd slap a couple of UPSs in on the computers but that wasn't a viable option in the late 80's for a small customer.
I can confirm this is an issue.
I've told this story a couple of times, so I'll be brief.
Back in the late 80's / early 90's I worked for a large retailer, our computer system ran on a pair of mirrored Compaq servers.
Every so often one or other of the servers would have a momentary brain fart, causing the tills to glitch, the main problem being that any sale in progress would terminate, but the stock issued to that sale would disappear from the system into a pending file and be restored overnight when pending sales were cancelled. This was a big problem if the customer had ordered the last of an item, as we would then be unable to sell that item until it was cleared the next day.
The support guys came and did their stuff; running power analysers, network sniffers, all kinds of tests, but the problem never arose when they where on site.
Until one day the manager's analogue cordless phone rang as she passed the comms room.
Clearly the EMP as her phone connected to the base station was enough to unsettle the fragile servers.
Swapping to a DECT phone was enough to fix the issue.
Anyone with a GSM based phone and being near anything with amp in it probably remembers the "duh duh duuuuh" type sounds the amp would pick up on it's input from the GSM phone going from "cell standby" to "making connection for call" before it rang.
Had similar
The landline (some cisco thing) back in late '90s early '00s would interfere with the adjacent Unix workstation's sound system. I never used the sound system but just before the phone actually rang the sound system would snap, crackle and pop.
This helped to enhance my tech aura when consulting with a user, I would interrupt saying "excuse me, I have to take this call" just before the phone rang.
Plenty of perplexed users. A BoFH that can actually see the future is a window far too open for most people.
No one tumbled to it before the phone system and handsets were upgraded to some boring voip thing.
"Aura" enchancement
I've always found that carrying, and when appropriate waving about, one of those orange plastic dead-blow mallets that comes with metal racking over said "miscreant equipment" significantly enhances both the efficacy and range of one's personal "IT Technician Aura".
A phoney story?