• (cs) in reply to Anomaly
    Anomaly:
    n_slash_a:
    faoileag:
    From Linux System Administrator's Guide @ about.com: "date only shows or sets the software clock" (emphasis by me).

    A hardware problem? Unlikely. A kernel problem? Unlikely. Some homegrown script trying to keep several servers synced on the same system time? Unlikely, after all two successive "date" calls deliver two different timestamps and the pattern looks too regular for a race condition (date calls vs. script).

    An executable named "date" that only serves one of two hardcoded dates alternatively? Now that's the most plausible scenario so far.

    Anyone with a better idea?

    It seemed that rather than order a new server, they just switched the VPN and FTP servers. So instead of the VPN randomly crashing, a FTP transfer will occasionally fail. Probably better, since most FTP clients can handle dropped chunks, but still a WTF that the root cause wasn't fixed.

    It was the other way around. They replaced a perfectly good VPN server with a broken server that disconnects all the time.

    heh

    "IT ... they just reused the VPN server for FTP!"

  • Joe (unregistered) in reply to M-x org-mode

    and pinball is too popular to buy parts just to make them look like something to fool them.

  • Norman Diamond (unregistered)

    If it's hard for programmers to get dates, it should be hard for system administrators to get dates too.

    This site's preview tells me this is posted some time in the future. It doesn't even have a date.

  • EmTeedee (unregistered) in reply to Norman Diamond

    I actually had something similar happening, with a weird kernel and a dual core processor, somehow each core kept it's own time and the scheduler assigned "date" to alternating cores. All went away after a kernel update...

  • Shinobu (unregistered) in reply to faoileag
    faoileag:
    From Linux System Administrator's Guide @ about.com: "date only shows or sets the software clock" (emphasis by me).

    A hardware problem? Unlikely. A kernel problem? Unlikely. Some homegrown script trying to keep several servers synced on the same system time? Unlikely, after all two successive "date" calls deliver two different timestamps and the pattern looks too regular for a race condition (date calls vs. script).

    An executable named "date" that only serves one of two hardcoded dates alternatively? Now that's the most plausible scenario so far.

    Anyone with a better idea?

    Yes. The best explanation is that the ‘screenshot’ is fake, as is probably almost the entire story.

  • Rudolf (unregistered)

    Hmm, either this is fake, or the 'date' command wasn't the real 'date' command.

    If the system clock was changing in the background, then it's a very big coincidence that it changes in sync with the 'date' command running. If the alternation between the displayed dates wasn't so consistent I could I see it being the clock changing, but I doubt it if the screenshot is a true representation.

    The thing is that if it was a fake 'date' executable, then how would that affect the VPN server? I'm fairly sure the VPN server wouldn't use the 'date' executable to get its timestamps.

    Also, did the date result alternate like this all the time, or just when the VPN connection dropped? If it's all the time, what did that have to do with the VPN connection dropping? If it was just when the VPN connection dropped, how did they happen to run the commands at just the right time?

    It definitely wasn't the motherboard though.

    (I'm tending towards this being fake. Or at least so messed with during the rewrite for the website that it doesn't make sense any more)

  • qazwsx (unregistered)

    It's just Erik Gern making up fake bullshit so he can have an excuse to practice his creative writing. He should be on fanfiction.net, not dailywtf.

  • Sarcasto (unregistered) in reply to Craig S

    +1 I would too!

  • ProgrammerBlues (unregistered) in reply to Norman Diamond
    Norman Diamond:
    If it's hard for programmers to get dates, it should be hard for system administrators to get dates too...

    Yeah, I'm a programmer and I didn't manage to get a date for Valentines :(

    Captcha: eros (how appropriate, maybe it's a sign I need to pray to the Greek God of Love in order to get a date on Valentines...)

  • Mr.Bob (unregistered)

    Alex is a shameless clock tease.

  • (cs) in reply to ProgrammerBlues
    ProgrammerBlues:
    Yeah, I'm a programmer and I didn't manage to get a date for Valentines :(
    This year it was February 14th. It's February 14th next year, too.

    You're welcome.

  • Cheong (unregistered)

    It's about time (!) to check whether ntp.conf contains multiple NTP server that does not agree the time with each other.

  • poster of the screenshot (unregistered) in reply to faoileag
    faoileag:
    poster of the screenshot:
    faoileag:
    An executable named "date" that only serves one of two hardcoded dates alternatively?
    If it was a script I never found it and it must have been installed at the dc.
    I must admit that I suspected the supplier of the wtf of having fabricated it.

    Since you as the supplier take care to answer me, this theory can now be best described as being "obviously wrong".

    But since you are here: care to shed some light on how much of the story is your submission and how much is embellishment?

    Only the screenshot was mine. It was hosted by a cheap "dedicated servers" company. When I complained for the second or third, they switched the motherboard out. As the problem took a week or so to reoccur after rebooting and that was their third attempt (all of which involved rebooting the live server without telling me first) I just cancelled the box. We moved dc shortly after that.

  • r00t (unregistered) in reply to faoileag

    i've actually seen this happen on some boxes, the time returned by date is off on some reads, always by a fixed amount, just like in the example given here. both the amount and the rate at which this problems occurs increases with uptime (it's zero initially, and usually stays at that for weeks or months). i'm suspecting some strange kernel and/or hardware problem, but never tried debugging it much... i ended up creating a nagios check for this, and manually rebooting the boxes as the problem occured. (curiosuly this hasn't happened for some years now... but happened regularly before (no configuration changes on the systems...)

    my test script (nagios check), another wtf in itself...: #!/bin/bash for ((n=0;n<128;n++)) ; do A=$(date +%s) B=$(date +%s) [[ $A == $B ]] && continue [[ $((A-B)) == -1 ]] && continue echo "CRITICAL - system time unstable" exit 2 done echo "OK - system time seems stable" exit 0

  • River Song (unregistered)

    fires weapon at Stetson Hello sweetie :)

Leave a comment on “Temporally Confused”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article