• The Balance (unregistered)

    Proscribe != Prescribe. They almost mean opposite things;

    "Following the proscribed steps" should have immediately seen Ray disciplined.

  • Dan (unregistered)

    Also known as "whoops, I accidentally made a fork bomb."

  • Iggy (unregistered) in reply to Dan
    Dan:
    Also known as "whoops, I accidentally made a fork bomb."

    Yes, during college we had a guy that made this kind of bomb.

    his nice little:

    for (i=0; i++; i <100)
{
 fork();
}

    so instead of nice 100 child processes there were quite a few more...

    the SUN workstation was not setup with user quotas, and with 10 clients connected via xdmcp this was not only a fork bomb, but the network load almost shut down the whole network in this building.

    as you guess: the building was hosting the main servers...

  • Tom (unregistered)

    You don't follow proscribed steps because, well, they are proscribed.

  • Shinobu (unregistered)

    Am I the only one who thinks it reading a tedious political tractate, just to find out it was about a lousy fork bomb, wasn't worth it?

  • faoileag (unregistered)

    The real wtf is that Ray's paycheck is so meager that buying the sys admins a couple of rounds of drinks takes "a large percentage" of it, amirite?

  • faoileag (unregistered) in reply to Shinobu
    Shinobu:
    Am I the only one who thinks it reading a tedious political tractate, just to find out it was about a lousy fork bomb, wasn't worth it?
    No, you are not.
  • QJo (unregistered)

    So a bit like:

    public String getId () { return this.getId(); }

    ... which is all too easy to perpetrate. Fortunately this bug is caught within seconds of running it.

  • QJo (unregistered) in reply to faoileag
    faoileag:
    The real wtf is that Ray's paycheck is so meager that buying the sys admins a couple of rounds of drinks takes "a large percentage" of it, amirite?

    The story is obviously set in Scandinavia, or Iceland, where alcohol is expensive.

  • Doctor_of_Ineptitude (unregistered) in reply to faoileag
    faoileag:
    The real wtf is that Ray's paycheck is so meager that buying the sys admins a couple of rounds of drinks takes "a large percentage" of it, amirite?

    You don't know the number of System Administrators in that department,and other nearby System Administrators that went to the pub. When the blame is so squarely on you, then a lot more such System Administrators pop up when you go and order the placating beer.

    Captcha: sagaciter. Hmmph, not much of a saga to cite, really.

  • Dave H (unregistered) in reply to faoileag

    It's the government, there were probably hundreds of "system administrators".

  • (cs) in reply to The Balance
    The Balance:
    Proscribe != Prescribe. They almost mean opposite things;

    "Following the proscribed steps" should have immediately seen Ray disciplined.

    I'd suggest that running a fork bomb was a proscribed step...

  • (cs)

    Further thought suggests strongly that this is NOT a fork bomb. No, what happens is that the script spawns a copy of itself and exits when the copy exits. So the process table fills, the Nth tries to spawn the N+1th and fails (allowing the failed invokation to exit, thus unwinding everything. Of course if it invokes itself without respecting failure conditions, and invokes itself multiple times during a single run, it may take some time to unwind fully.

    Bad anonymousification, I'd say.

  • (cs) in reply to The Balance
    The Balance:
    Proscribe != Prescribe. They almost mean opposite things;

    "Following the proscribed steps" should have immediately seen Ray disciplined.

    QFT. Is it so difficult to find editors with some familiarity with the English language?

  • (cs)
    Like magic, budget was found for a new data change management and scheduling system.

    Yay, happy ending. I hope. I suppose it could be herbl.

  • Programmer Dude (unregistered)

    Heck, the Sys Admins should be the ones buying the beer! They neither found nor fixed the problem. They just waited on the DEV to show up, went and got him and then scratched their poopers and let him figure it out.

    Yeah, this round should be on the Sys Admins.

  • faoileag (unregistered)

    "(ray) followed the proscribed steps"

    Leaving the typo aside, this tells us that a detailed guide existed to test any scripts that are meant to be run on the production server. This is obiously good, as it minimizes the risk of something strange happening.

    Why then, are not all scripts tested on the test server?

    Had rous_at_job.sh been tested on the test server, the infinite recursion would have been detected on the test server instead of on the production server after a night of standstill.

  • faoileag (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Further thought suggests strongly that this is NOT a fork bomb.
    Well, I read the story as "rous_at_job.sh's sole raison d'etre is to start rous.sh with some parameters once when called from whatever service/daemon calls those "AT" scripts. And then it is a fork bomb because rous_at_job.sh is not meant to call itself.
    Steve The Cynic:
    No, what happens is that the script spawns a copy of itself and exits when the copy exits.
    And the copy generates another instance of itself and exits, when that copy exits, so the original script exits when the copy created by the copy exits. Only the copy of the copy starts a copy of itself as well, waiting for that copy to exit before it exits...

    To understand recursion you have first to understand recursion.

    Captcha conventio: by conventio all recursive functions should include a terminating condition.

  • my name (unregistered) in reply to oheso
    oheso:
    The Balance:
    Proscribe != Prescribe. They almost mean opposite things;

    "Following the proscribed steps" should have immediately seen Ray disciplined.

    QFT. Is it so difficult to find editors with some familiarity with the English language?

    Based on how many other typos there were (I counted three, but might've missed some), I think we already know the answer to this....

  • Black Bart (unregistered)

    Calf leather bound volumes of printouts? In industry, we always used blue plastic leather bound volumes of printouts.

  • faoileag (unregistered) in reply to Black Bart
    Black Bart:
    Calf leather bound volumes of printouts? In industry, we always used blue plastic leather bound volumes of printouts.
    You had blue plastic leather bound volumes? You were lucky! Where I once worked, we had to make do with paper clips!
  • (cs) in reply to my name
    my name:
    (I counted three, but might've missed some)

    You missed some.

  • (cs) in reply to faoileag
    faoileag:
    You were lucky! Where I once worked, we had to make do with paper clips!

    LUUUUUUUUUXURY!!!!

  • (cs)

    Those system administrators drinking like there is no tomorrow.

  • (cs) in reply to oheso
    oheso:
    faoileag:
    You were lucky! Where I once worked, we had to make do with paper clips!

    LUUUUUUUUUXURY!!!!

    ... we used to have to copy the contents of the screen onto slates with pieces of chalk. Tiny little pieces, that is, not fresh new out-of-the-box sticks of chalk, but the remnants handed down to us from when the bosses had finished with them.

    Imagine my embarrassment once when I realised too late that I was actually holding a wax crayon. They made me go out to the shop to buy a new slate, on my own time and with my own money.

  • Sizik (unregistered)

    rous: Recursions of Unusual Size?

  • Dave (unregistered) in reply to Sizik
    Sizik:
    rous: Recursions of Unusual Size?

    ROUs of Unusual Size.

  • (cs)

    The server was only MOSTLY down. It was a little up. When a server is completely down, there's only one thing you can do: take all its drives and look for interesting data.

  • (cs) in reply to Dave
    Dave:
    Sizik:
    rous: Recursions of Unusual Size?

    ROUs of Unusual Size.

    I've seen worse.

  • (cs)

    TRWTF is the reference to the Matrix sequels that never happened.

  • Blah (unregistered)

    I'm confused. Which WTF was I supposed to be looking for here? The dev recursively calling his script till the server assumed a digital fetal position? That the sys admin knew what was causing the problem and waited for the dev to get in? Or that the server had alerted the admins before-hand and they did nothing and THEN waited for the dev?

    I think maybe I need some more background. Was Ray the office dick and they just threw him under the bus instead of fixing it or were they that lazy?

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    ... we used to have to copy the contents of the screen onto slates with pieces of chalk. ...

    You had SLATES???

  • (cs)
    "Fezzik's down!", he said.

    "Inconceivable!"

  • (cs) in reply to operagost
    operagost:
    "Fezzik's down!", he said.

    "Inconceivable!"

    Nah, that was an everyday occurrence with Fezzik. He's the Monica Lewinsky of servers named for fictional giants.

  • anonymous (unregistered) in reply to Iggy
    Iggy:
    Dan:
    Also known as "whoops, I accidentally made a fork bomb."

    Yes, during college we had a guy that made this kind of bomb.

    his nice little:

    for (i=0; i++; i <100)
{
 fork();
}

    so instead of nice 100 child processes there were quite a few more...

    the SUN workstation was not setup with user quotas, and with 10 clients connected via xdmcp this was not only a fork bomb, but the network load almost shut down the whole network in this building.

    as you guess: the building was hosting the main servers...

    Psh, by my calculation that's only 1,267,650,600,228,229,401,496,703,205,376 processes. Your server couldn't handle that?

    faoileag:
    And the copy generates another instance of itself and exits, when that copy exits, so the original script exits when the copy created by the copy exits. Only the copy of the copy starts a copy of itself as well, waiting for that copy to exit before it exits...
    The person you replied to was saying that eventually, when there was no longer any room to start a (N+1)th copy, the Nth copy would exit without generating another instance of itself - it would try, fail, and exit with an error code.
  • golddog (unregistered) in reply to Matt Westwood

    But you tell the young people today that, they'll never believe you.

  • (cs) in reply to operagost
    operagost:
    "Fezzik's down!", he said.
    "Inconceivable!"
    That word. I do not think it means what you think it means.
  • (cs)

    Stick a ()(&&); in it and turn it over, it's done.

  • (cs) in reply to faoileag
    faoileag:
    Steve The Cynic:
    Further thought suggests strongly that this is NOT a fork bomb.
    Well, I read the story as "rous_at_job.sh's sole raison d'etre is to start rous.sh with some parameters once when called from whatever service/daemon calls those "AT" scripts. And then it is a fork bomb because rous_at_job.sh is not meant to call itself.
    A fork bomb, conventionally, is an unbounded fork(), so that at no time is it possible (without mass kill()ing if you can manage it) to stop the creation of new fork()ed copies of the original program. 
    int main(void) {
while(1) fork();
return 0;
}

    This is the simplest example.

    faoileag:
    Steve The Cynic:
    No, what happens is that the script spawns a copy of itself and exits when the copy exits.
    And the copy generates another instance of itself and exits, when that copy exits, so the original script exits when the copy created by the copy exits. Only the copy of the copy starts a copy of itself as well, waiting for that copy to exit before it exits...
    Yes, and eventually the process table fills and one of the starts fails, at which point the whole structure collapses and the system is back to normal. If the script (incorrectly) attempts several (one after another) starts of the child script (invoking itself instead), the time to complete the unravelling is exponential, as pow(num_starts_per_script, size_of_process_table), which can get to be very large. (I worked at a place a few years back which ran Solaris in versions from 8 to 10 on 192-core ultrasparc iron, and those machines had 8K process tables. A pow(N, P) job started early enough in the boot cycle would have an exponent of more than 7000, and even if N was only 2 (two invokations per run), you are talking about a grand total of 2**7000 invokations, which is a very large number, on the order of 10**2100. Even largish iron like those machines would have a hard time with that. Even at the normal steady state on those machines, with around 7000 processes active, you still get 2**1000 invokations if N==2, about 10**300. At one invokation per 100µsecs, that's 10**296 seconds, quite a long time.
  • Bruce Johnson (unregistered) in reply to oheso

    Not sure about the editing, but I take responsibility for all of the typos. After all, English is my first (and only) language.

  • QJo (unregistered) in reply to Bruce Johnson
    Bruce Johnson:
    Not sure about the editing, but I take responsibility for all of the typos. After all, English is my first (and only) language.

    Voilà le vrai ce qui le baise.

  • neminem (unregistered)

    The actual bug is pretty lame and boring. The Real WTF, though: how the frack do you run a crazy number of required tests, without any of your tests actually testing whether the thing you're testing actually, you know, even works at all? That makes no sense. I'm honestly baffled.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Doctor_of_Ineptitude
    Doctor_of_Ineptitude:
    You don't know the number of System Administrators in that department,and other nearby System Administrators that went to the pub.
    Especially if one of the System Administrators is named Simon.
  • nitPicker (unregistered) in reply to Iggy
    Iggy:
    Yes, during college we had a guy that made this kind of bomb.

    his nice little:

    for (i=0; i++; i <100)
{
 fork();
}

    so instead of nice 100 child processes there were quite a few more...

    Actually, this code will never fork. i is set to 0. i is tested but is 0 so the for loop never executes.

    Just sayin'.

  • faoileag (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    Doctor_of_Ineptitude:
    You don't know the number of System Administrators in that department,and other nearby System Administrators that went to the pub.
    Especially if one of the System Administrators is named Simon.
    That wouldn't set you back financially too much - you, Simon and the PFY. There are no other system adminstrators before Simon.
  • (cs)

    This is quite possibly the worst-written article I've ever seen on the DailyWTF. Pointless rambling intro, typos, grammar errors, vocabulary errors, confusing narrative, mangled metaphors, greengrocer's apostrophes, shoehorned movie references, and a WTF that turned out to be some trivial, easily-fixed thing.

    If I didn't know better I'd assume someone sat down to deliberately write a parody of everything that these articles get mocked for.

  • me (unregistered) in reply to Zylon
    Zylon:
    This is quite possibly the worst-written article I've ever seen on the DailyWTF. Pointless rambling intro, typos, grammar errors, vocabulary errors, confusing narrative, mangled metaphors, greengrocer's apostrophes, shoehorned movie references, and a WTF that turned out to be some trivial, easily-fixed thing.

    If I didn't know better I'd assume someone sat down to deliberately write a parody of everything that these articles get mocked for.

    You mean greengrocers' apostrophes. Just sayin' ;-)

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to nitPicker
    nitPicker:
    Iggy:
    Yes, during college we had a guy that made this kind of bomb.

    his nice little:

    for (i=0; i++; i <100)
{
 fork();
}
    so instead of nice 100 child processes there were quite a few more...
    Actually, this code will never fork. i is set to 0. i is tested but is 0 so the for loop never executes.

    Just sayin'.

    Mmm, yes, it needs to be changed to ++i to work properly.
  • OldCoder (unregistered) in reply to neminem
    neminem:
    The actual bug is pretty lame and boring. The Real WTF, though: how the frack do you run a crazy number of required tests, without any of your tests actually testing whether the thing you're testing actually, you know, even works at all? That makes no sense. I'm honestly baffled.
    The tested script might have worked; we'll never know.

    What failed was the cobbled-up and never-tested invocation script which ran itself rather than the test script.

  • anonymous (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    nitPicker:
    Iggy:
    Yes, during college we had a guy that made this kind of bomb.

    his nice little:

    for (i=0; i++; i <100)
{
 fork();
}
    so instead of nice 100 child processes there were quite a few more...
    Actually, this code will never fork. i is set to 0. i is tested but is 0 so the for loop never executes.

    Just sayin'.

    Mmm, yes, it needs to be changed to ++i to work properly.
    More likely Iggy meant for (i = 0; i < 100; ++ i) and just misremembered the syntax. Still a good catch, I suppose. I didn't notice it.

Leave a comment on “All Your RAM Are Belong to Us”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article