• (cs) in reply to Johnny Syntax
    Johnny Syntax:
    Just use Java and get over it!
    Java doesn't fix this kind of thing either - not even close.

    A server product I once worked with was written in Java. Most of the clients using this product had a script that would kill the server once every 24 hours and then restart it to keep things going reliably.

    The problem was in two places: 1) Badly written thread handling in the product. 2) The Java garbage collector.

    The shoddy thread handling was somewhat fixed. However, sooner or later, all the threads would get used up and never come back.

    Without a total rewrite of the code, not much could be done about the Java GC. The product would create/destroy bajillions of small objects, then a request would come in to allocate a huge object. The GC would merrily go on for a minute, two or ten, freezing out any threads and punching the CPU usage to 100% for the duration.

    Hork, pffht! on Java.

  • esse (unregistered) in reply to Domo Arigato
    Domo Arigato:
    Wouldn't a UPS controlled by the 2nd machine have beeen easier? Just cycle it when the machine stopped responding.

    They couldn't afford a new server, what makes you think they could afford a UPS?

  • edgood (unregistered) in reply to Morty

    if you have any sysadmin in your blood you have done something like this, if not exactly this before

  • Bruno (unregistered) in reply to programmer x

    This, of course is one of many good illustrations of the real meaning of >boot< and >re-boot<. Sorry, had to say it, going back to work.

  • (cs) in reply to programmer x
    programmer x:
    This reminds me of a story from an ex-IBM employee who told me a story about one of their old mainframes which didn't quite work right. Every now and then it would just stop working for whatever reason and had to be reset, losing lots of impoertant information.

    This happened fairly often and they decided to rebuild it from the ground up to fix whatever was wrong with it. No luck: it still stopped working quite regularly, so they posted a guy near it at all times so that when it shuts down he just has to hit the button and it'd restart. Eventually, the guy got so pissed off at the machine he just kicked it; somehow it started up again with no lost information at all.

    The next day he shuffled over to my teacher and said, "last night when I it stopped I just kicked it, and it just started working again."

    My teacher looked at him and asked, "where did you kick it?" So the guy points it out and my teach got out a peice of chalk and put a circle where he kicked the machine. "Next time it breaks, do that again."

    So, eventually it broke again and the guy kicked it. The machine whirred back to life the way it did last time. After a week or two of doing this without losing any information they decided to report it to a senior manager.

    His response? "Well, add it to the manual."

    This is funnier than the original story...

  • Shinobu (unregistered)

    Awww... a Christmas story. How sweet.

  • Kuba (unregistered) in reply to D. T. North
    D. T. North:
    Domo Arigato:
    Wouldn't a UPS controlled by the 2nd machine have beeen easier? Just cycle it when the machine stopped responding.

    Wouldn't that cause havoc on the filesystem? I'm assuming this is a unix-like system and the reset button triggers a 'shutdown -r now' command, which at least unmounts the hard drives before rebooting. Power cycling the PC wouldn't unmount them, and I imagine it would eventually corrupt the system.

    A reset is a reset. At least on PC-based servers, I've never seen a "soft" reset. ACPI-programmable power buttons - yes. Reset is always hardwired straight into the chipset. Like it's supposed to.

    Some servers even have NMI button, which is way cool, since last time I ever saw one was when I added it to a ZX Spectrum in the 80's.

  • (cs) in reply to jo42
    jo42:
    Johnny Syntax:
    Just use Java and get over it!
    Java doesn't fix this kind of thing either - not even close.

    A server product I once worked with was written in Java. Most of the clients using this product had a script that would kill the server once every 24 hours and then restart it to keep things going reliably.

    The problem was in two places: 1) Badly written thread handling in the product. 2) The Java garbage collector.

    The shoddy thread handling was somewhat fixed. However, sooner or later, all the threads would get used up and never come back.

    Without a total rewrite of the code, not much could be done about the Java GC. The product would create/destroy bajillions of small objects, then a request would come in to allocate a huge object. The GC would merrily go on for a minute, two or ten, freezing out any threads and punching the CPU usage to 100% for the duration.

    Hork, pffht! on Java.

    Alternatives to that "stop the world" method of GC have been available since Java 1.4, i.e. for about 5 years. Even before that, you could probably have solved (or at least reduced) the problem by calling System.gc() manually once in a while during the "create/destroy bajillions of small objects" phase.

  • Jon (unregistered)

    Just in case you have the same trouble...

    http://www.bb-elec.com/bb-elec/literature/pstone.pdf

  • Shadowbird (unregistered)

    The last paragraph is just way too sad.

  • Robin Wilton (unregistered) in reply to programmer x

    I heard a variant of that last story; instead of a mainframe, it was a large Gizmotron which entirely automated the work of its designer and creator... who was therefore promptly made redundant.

    A couple of years of flawless operation were followed by intermittent unexplained failures of the Gizmotron. In a cold sweat, the manager tracked down the inventor and begged him to come back and fix the machine. Still somewhat bitter, he agreed, but explained that it would have to be at his special consultancy rate. The manager wasn't about to tell him to get lost, so agreed at once.

    On site, the inventor walked slowly around the Gizmotron, listening carefully. Then he stopped, took a piece of chalk from his pocket and marked a small "X" on the casing.

    "Open up the casing there", he said; "you'll find the problem, and it should be pretty easy to fix". It proved to be as he had said, and the manager heaved a huge sigh of relief.

    Two days later the invoice arrived. It read, simply: "For fixing Gizmotron: $10,000.02"

    The manager threw a fit. He wrote back to the inventor saying the charge was exorbitant, and he couldn't possibly pay it without a fully itemised statement of how the total had been arrived at. A new invoice arrived by return of post:

    "Cost breakdown for Gizmotron repair:

    Cost of materials: $0.02 Knowing where to put the "X": $10,000"

  • GeorgeOfTheJungle (unregistered) in reply to programmer x

    Hence the term Reboot. Okay, I know everyone was thinking it, but nobody was going to say it!

  • Geekguy (unregistered) in reply to programmer x

    Isn't that the whole point of an IBM machine.

    Its better Manually. (IBM).

  • Pedro Melo (unregistered)

    Its the last paragraph that makes this art. The fact that they unplugged, moved it to the corner and plugged it again demonstrates the IT department mentality.

  • Ellie Greene (unregistered)

    I am sad for the poor neglected robot, spending its last days vainly searching for purpose, attempting to fulfill its purpose one last time.

    -ellie

  • (cs)

    Hmm, this thread appears to have been rendered unclean by at least two spambots. Boo.

  • Truthiness (unregistered)

    Its simple in 2010, We just hire an indian to stand by the machine.

    Reboot now?

  • tester (unregistered)

    why do I feel sorry for that computer? :(

  • me (unregistered) in reply to Pink Duck

    no, the replacement had a different ip address, so when the robot pinged the old one, it got no redponse.

  • eric bloedow (unregistered)

    one of the comments reminds me of a story i heard: a printer always crashed when trying to print any job with more than 50 pages-UNLESS someone watched it, then it would work properly! the problem turned out to be caused by static buildup, and it didn't happen when someone was watching, because they would usually LEAN ON IT, thus grounding it! so the addition of a grounding wire fixed the problem...temporarily! when the printer was moved to a different location, the problem came back, because the grounding wire was left behind!

  • ~~~ (unregistered)

    "It was a long time since the Bustler had been so silent.", or how to make an offog.

  • Anonyguest (unregistered)

    This story reminds me a software issue in Fortigate software couple of years ago. When you enabled IPS the thing will hang in a few hours. As we had some upcoming holidays (so no-one would be on-site), and some services had to be accessible all the time, we came up with an arduino-based solution. Frankenduino basically pinged a host outside of our LAN every five minutes, and when it failed - it just cut power to the Fortigate for a few seconds, then it would wait for like 5 minutes. Rinse and repeat. Saved our holidays.

Leave a comment on “ITAPPMONROBOT”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article