• Tom Limoncelli (unregistered) 
    A better replacement would be:

    start oracle
    while true ; do sleep 9999 ; done

    An even better replacement would be:

    start oracle
    wait

    but that only works if the 'start oracle' leaves child processes around.

    However, the *real* better solution is to look at the root cause. The root problem here is that someone noticed that oracle dies as soon as the startup script exits.  That's because the script gets a HUP and that kills all the children.  The real solution is the have Oracle change the database so that it properly detaches from the terminal.

    However, detaching from the terminal completely is very difficult... it requires READING THE DAMN STEVENS BOOK which anyone writing Unix code should know anyway.

    However, since that requires ACTUALLY KNOWING WHAT YOU ARE DOING here is a solution for those weak-minded souls.

    (((( start oracle & ) & ) & ) & ) &

    It's ugly, but it works.  I believe AT&T-based Unix requires 2 sets of ()'s and BSD-based Unix requires 3 sets of ()'s.  I do 4 sets to be paranoid.

    This has solved many problems for badly written code over the years.  I believe I first learned it from Rich Salz, author of INN.
  • thebilliardplayer (unregistered) in reply to Jojosh_the_Pi
    Jojosh_the_Pi:
    Anonymous:

    But Carbon-14's half-life is about 5,730 years, so that means about 2^(-1.02*10^8) percent of your client will be left by that point...


    Actually, it's 2^-(1.02*10^8) percent.   (-1.02*10^8 ends up being positive)

    (Of course, everyone knows what you meant.  But why participate in the TheDailyWTF forums without the chance to try to sound smart by pointing out minutae even though everyone will forget by tomorrow?)




    This sort of epitomises your comment, but WTF, here I go...

    "Actually, it's 2^-(1.02*10^8) percent.   (-1.02*10^8 ends up being positive)"
    This isn't pointing out minutae, this is making a WTF of operator precedence (with the added bonus of doing it in an attempt to show someone up)

    Jesus wept. Of course, I saw the point of your comment (the way people point out minuate for absolutely no reason, other than they're nerds), but what's the point o^C ERROR - STACK OVERFLOW


  • Thygrrr (unregistered)

    The best WTF in a long time!

    AWESOME! :D



    (knowhutimean?)

  • Hex (unregistered) in reply to Satanicpuppy

    "On the other hand, the epoch stuff will be much easier to correct than the stupid y2k error, because the next common datasize up from 32 is 64, and 64 will last 584,942,417,355 years, which should be enough for anyone."

    That's exactly the kind of thinking that got us into trouble in the first place.

  • bob (unregistered) in reply to uber1024

    Well, its only a problem for half of them...

  • Joe (unregistered) in reply to GoatCheez

    I look at this and think, well, it could be fixed (-ish) by using:

    sleep $(( 2147483647 - date +%s ))

    but I'm not sure if that's a happy fix.  It means that after the infocalypse on Jan. 19, the script will start saying "sleep:  invalid option" when it dies.  Hopefully sleep would be fixed by then.

    So the real fix would be:

    sleep 1000000000 || sleep $(( 2147483647 - date +%s ))

    Now that is a piece of code that should be very clearly commented.  And I still think it sucks.

  • Grumpy Physicist (unregistered)

    Now, if they used VMS, there wouldn't be a problem until the year 31,000 or so.

    Except, of course, the problem of using VMS for the next 29,000 years.

  • Freddy (unregistered) in reply to Ibiwan
    Anonymous:
    Anonymous:
    JBL:
    Digitalbath:

    JBL:
    Anonymous:
    Got to love code that requires continued maintance

    Heck, if they upgrade the OS to 64-bit, then no problem.

    On the other hand, I'll be in my early 70's by then. I look forward to not receiving a Social Security check for a few years while the govt sorts it out on their 30-year-old servers.

    On the other other hand, that check will be worth about 85 cents anyway, yes?

    [and how long until someone manages to fit "none of us has a girlfriend anyway" in here?]

    Stop it you crazy sexist.  How dare you refer to women as "girlfriends."  That singles them out as compared to "boyfriends."  Please use "significant other" from now on, or I will stick our my lower lip and pout.

    </OverflowingSarcasm>


    As you wish.


    Don't you mean "I love you"?


    You keep on using that phrase... I do not think it means what you think it means...


    Last time I opened a mail with that title I got a lot of angry comments from my friends.
    Does that mean I'm popular?
  • (cs) in reply to Bus Raker
    Bus Raker:

    Satanicpuppy:
    64 will last 584,942,417,355 years, which should be enough for anyone.

    Well we are at least 24000,000,000 years away from the 'Big Crunch', so 64 should do for now.  Any more and the scope could possibly be beyond this universe and our budget.

    http://en.wikipedia.org/wiki/Big_Crunch

    /me wonders how many bits would be needed to cover the entire lifetime of the universe - in units of Planck time...

  • Anonymous Coward (unregistered) in reply to GoatCheez

    That's one poor implementation of sleep.  The linux coreutils-5.94 doesn't have that problem.  In fact of all the platforms that the SourceForge.net compile farm support, only OpenBSD and Solaris 9 (for x86) get it wrong.

  • Benhaha (unregistered) in reply to Eric L

    You are wise.

    In addition, if the startup script is sleeping, you can cause a graceful shutdown with a SIGTERM. (Sleep will exit immediately, and "stop oracle" will execute.)

    Also may be useful if it has been started by a process which expects to be able to send a SIGTERM to shut it down again.

    Verdict: Not stupid.

  • roxorz (unregistered) in reply to Satanicpuppy
    Satanicpuppy:
    If you work with unix enough, you see plenty of epoch errors. I've met plenty of windows guys who don't even understand the reasoning behind it...."The number of seconds since 1/1/70? WTF?"

    On the other hand, the epoch stuff will be much easier to correct than the stupid y2k error, because the next common datasize up from 32 is 64, and 64 will last 584,942,417,355 years, which should be enough for anyone.


    lulz...  In 584 trillion years the universe itself will have ended and restarted about 6000 times.
  • aka (unregistered) in reply to AlpineR

    "Who is more foolish the fool or the fool who follows him?"

  • asgeirn (unregistered) in reply to Satanicpuppy

    The number of seconds since 1/1/70 right now was 61,109,675,529 by the way.  This takes the 11-day Julian to Gregorian leap into account, but not leap seconds.

  • Peter da Silva (unregistered) in reply to JBL

    I've been using a real 64-bit OS since the mid '90s. On hardware that's relentlessly 64-bit, the late lamented Alpha.

    Or so I thought until I dug around in /usr/include and noticed that time_t on tru64 was still 32 bits long.

    Because, of course, there's all kinds of external on-disk and on-wire formats that expect 32-bit time.

    Whereupon I had a flashback to 1980, when I was porting my programs from V7 on the PDP-11 to 4.1 BSD on the VAX, and found that sizeof (int) == sizeof (long). That was a real WTF moment. And I never got a good explanation from anyone why they didn't make long 64 bits on 32-bit machines back then.

    After all, almost all the C code in the world at the time was written on 16-bit machines where sizeof (long) == 2 * sizeof (int), and an awful lot of it broke and had to be fixed when that wasn't true any more. If they'd done that, Bereley UNIX, the Berkeley TCP/IP stack and the standard TCP applications ... the ones used on virtually every commercial OS including Windows NT and VMS, would have been developed in an environment where 64-bit arithmetic was as easy and obvious as 32-bit had been on the PDP-11... and a few unfortunate 32-bit values like time_t might not be 32-bits.

    Something to consider next time I've got a time machine and a spare afternoon.

  • Izak Burger (unregistered)

    Probably a hack so they can hit ctrl+c to stop the sleep process and have oracle shut down.  Always better if you can use pause(2)...

  • Domingo Galdos (unregistered)

    The reason it's done that way is so that you can bring the database down in an orderly fashion just by killing (as in with a signal) the sleep process.

  • nite (unregistered) in reply to mathew
    Anonymous:

    No, what he should have done is written a proper /etc/init.d/oracle service start script, and symlinked it to /etc/rc5.d/S99oracle, so that when the server is rebooted the database starts up automatically.



    Assuming your default runlevel is 5, yes. On the other hand, defaulting to runlevel 5 might not be the brightest of ideas on a typical Solaris box.
  • (cs) in reply to Ged

    Anonymous:
    Satanicpuppy:
    If you work with unix enough, you see plenty of epoch errors. I've met plenty of windows guys who don't even understand the reasoning behind it...."The number of seconds since 1/1/70? WTF?"

    On the other hand, the epoch stuff will be much easier to correct than the stupid y2k error, because the next common datasize up from 32 is 64, and 64 will last 584,942,417,355 years, which should be enough for anyone.


    Just as "640k should be enough for anyone"... :)

    That reminds me of our Computer Science teatcher who was talking about character encodings, first mentioning the good old ASCII, then UTF-8 which apparently has all the characters we need to encode. And, he emphasized, enough to code all the Chinese and even Klingonese characters. And dudes and dudettes, he was freaking serious about the Klingons. He wasn't kidding, he was just totally out there. :D

    Of course he was serious about Klingons.  There have been about a million copies of the English-Klingon dictionary sold in this country.  You're one of those religious nuts that don't believe in Klingons, aren't you???

  • (cs) in reply to Ibiwan
    Anonymous:
    Anonymous:
    JBL:
    Digitalbath:

    JBL:
    Anonymous:
    Got to love code that requires continued maintance

    Heck, if they upgrade the OS to 64-bit, then no problem.

    On the other hand, I'll be in my early 70's by then. I look forward to not receiving a Social Security check for a few years while the govt sorts it out on their 30-year-old servers.

    On the other other hand, that check will be worth about 85 cents anyway, yes?

    [and how long until someone manages to fit "none of us has a girlfriend anyway" in here?]

    Stop it you crazy sexist.  How dare you refer to women as "girlfriends."  That singles them out as compared to "boyfriends."  Please use "significant other" from now on, or I will stick our my lower lip and pout.

    </OverflowingSarcasm>


    As you wish.


    Don't you mean "I love you"?


    You keep on using that phrase... I do not think it means what you think it means...

    My name is Inigo Montoya!  You kill my father!  Prepare to die!

  • Glug (unregistered) in reply to Bus Raker
    Bus Raker:

    I think he should set up an autoreminder for the AM of 11/18/2034.

     

    I was thinkin', I'd give it an extra day's warning, don't wanna cut it too short findin' a solution.  Heck, an extra 3 days, in case that day is a weekend.  Heck, an extra week, in case whoever was on vacation.  Heck, let's make it an extra month to account for plenty of time for a permanent solution, and any extra vacation days one might be taking due to changes in cultural norms.

  • Seth (unregistered) in reply to Satanicpuppy

    You're joking, right?

    Leaving aside all of the broken code out there, what are you going to do with billions of data files where the time was written as a 32-bit signed number?  Esp. in those apps where somebody was hurried (or just lazy) and used

       write(fd, s, sizeof(*s));

    to write the 's' data structure.

    The only bright side is that the disks themselves should be easy to handle, at least as long as there's a version field in the filesystem's volume header that indicates whether the file's timestamps are 32- or 64-bits.

  • (cs) in reply to uber1024
    uber1024:
    Satanicpuppy:
    the next common datasize up from 32 is 64, and 64 will last 584,942,417,355 years, which should be enough for anyone.
    One of my clients is a huge block of carbon-14, so it's not okay to them.
    Not even a huge block of U235 survives that long...
  • Shave a 0 off the sleep line.. (unregistered) in reply to GoatCheez

    Well duh.. if you just took the sleep out the script would stop the server right away ;-)

Leave a comment on “The Harbinger of the Epoch ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article