Live data from Hacker News

Every time we lift a pallet from the shipping room, the server times out (2006)

reddit.com

51–60 of 88 posts

Re: Every time we lift a pallet from the shipping room, the server times out (2006)

#52
post #34

Earlier quoted context omitted.

"We just don't think a Linux partition on a mainframe makes a lot of sense. It's kind of like having a trailer park in the back of your estate." That gave me more than a few giggles.

That line pulled me up short too. What an interesting analyses of the scene. I always got the impression Linux was looked down on early on (learned about Linux very late), and there you go.

Linux was, at the time, a bit flaky and lower performing than the various enterprisey UNIX flavors. X86 servers had similar catching up to do as well.

Re: Every time we lift a pallet from the shipping room, the server times out (2006)

#53

Well my best-worst debugging story concerns a friend's work based email account and Microsoft Outlook (in 2012). Occasionally it would fail to connect to send email to the server, just randomly. Obvious troubleshooting ensued, web traffic worked, could ping the email server, could connect with telnet and read email that way; Thunderbird worked. Created a new account, that would work for a while and then fail again. L…

Sounds like someone forgot to call this function, and maybe most of the systems were big-endian, so it didn't matter, but one was little-endian: https://linux.die.net/man/3/ntohl

Re: Every time we lift a pallet from the shipping room, the server times out (2006)

#54
post #36

Earlier quoted context omitted.

Not forgetting the classic "magic / more magic" switch: http://catb.org/esr/jargon/html/magic-story.html

Just the kind of bug which seems ridiculous as a bug report, but turns out to be true. Like the "OpenOffice.org won’t print on Tuesdays" bug, or the bug which crashed the computer when the general visited. Or the one when the server went down whenever a certain guy had a support ticket.

Do you have a link for the one with the general visiting? Sadly a google search just gave stories of military officers in plan crashes.

Re: Every time we lift a pallet from the shipping room, the server times out (2006)

#56

Well my best-worst debugging story concerns a friend's work based email account and Microsoft Outlook (in 2012). Occasionally it would fail to connect to send email to the server, just randomly. Obvious troubleshooting ensued, web traffic worked, could ping the email server, could connect with telnet and read email that way; Thunderbird worked. Created a new account, that would work for a while and then fail again. L…

Similar to the UK academic network JANET's problems with computer science department emails in the late eighties/early nineties. JANET used X.25 before transitioning to TCP/IP, with its own idiosyncratic email addressing that reversed the order of the domain name segments (relative to DNS order) in an email address. So, a University of Edinburgh CS department members with an address like 'grkvlt@cs.ed.ac.uk' was translated into user 'grkvlt' and host 'uk.ac.ed.cs' then promptly sent off to Czechoslovakia by overly-keen international mail gateways. This led to many CS mail server sub-domains gaining an initial departmental 'd', thus 'dcs', giving 'dcs.ed.ac.uk', 'dcs.gla.ac.uk' and so on...

Re: Every time we lift a pallet from the shipping room, the server times out (2006)

#57

Well my best-worst debugging story concerns a friend's work based email account and Microsoft Outlook (in 2012). Occasionally it would fail to connect to send email to the server, just randomly. Obvious troubleshooting ensued, web traffic worked, could ping the email server, could connect with telnet and read email that way; Thunderbird worked. Created a new account, that would work for a while and then fail again. L…

Might well be the parsing. Many people might use \d+.\d+.\d+.\d+ or worse.

I.e. not escaping the .

Re: Every time we lift a pallet from the shipping room, the server times out (2006)

#59
Back in the late 80's I was working on an X.25 gateway. We had it installed at a Wall Street firm. It had a problem where it would accumulate thousands of CRC errors in just a few minutes.

We knew the problem was on the customer premises because we had loaded the gateway down using the same test suite. We ran them through everything. Their point was when they plugged the scope on both sides of the connection and loaded the link with a loop back test, they had no problem.

I get on a plane. We have the scopes hooked up on both sides and the guys in the data center are on the phone talking. We load up the test suite and no errors occurred. Scratching heads, we watched it not fail for a half hour. The consensus was we needed to regroup and come back at the problem from a different angle. The data center guys agreed. Then, suddenly on our scope, we got like 500 CRC errors...

I said to the DC guys "what did you just do? We're getting CRC errors" "Nothing" "You didn't touch anything?" "No we just unplugged the scope from the patch panel" "Try plugging it back in please"

And the CRC errors stopped. Faulty patch panel diagnosed.

The firm probably paid $25k in consulting fees for that diagnosis. But for me, the lesson that my tools might alter what I am observing was priceless.

Re: Every time we lift a pallet from the shipping room, the server times out (2006)

#60
In college we had a similar scenario when a UPS delivery truck making it's routine stop at a fairly consistent time each day caused connectivity to degrade. If I remember correctly, the solution was discovered following a UPS strike in the late 90s.
Post reply on HN