• (cs) in reply to Uli
    Uli:
    The name is Börek, you can't spell turkish food without umlauts.

    You just did.

  • (cs) in reply to eViLegion
    eViLegion:
    QJo:
    The real WTF is Turkish pizza, amirite?

    I'd say TRWTF is ignorant new worlders calling it turkish pizza, because they don't know the word Lahmacun, but they have heard of turkey and pizza.

    Watch out for the difference between "turkey" and "Turkey"...

  • Chad Garrett (unregistered) in reply to Steve The Cynic
    Watch out for the difference between "turkey" and "Turkey"...

    And FYI, "turkey" is actually named after Turkey: http://en.wikipedia.org/wiki/Turkey_(bird)

  • (cs) in reply to Daniel
    Daniel:
    Small math correction to something that was noted above: on a somewhat regular system, this would have a 1/32768 chance of killing a process with randomly varying PID each day, and thus only have a 50% probability of happening once in

       50% = [complement of not happening]^[this many times in a row]    ½ = (1−1/2¹⁵)^(365.25⋅{years})    ⇒ ln(½)/ln(1−1/2¹⁵)/365.25 = 62 years.

    Either $PIDMAX was set to something much lower (but still higher than 21342, so that is not really plausible), or the process owned a multitude of PIDs that all caused the application to crash on SIGTERM. To crash with 50% certainty every 6 months, it would have to average on 124 vulnerable PIDs at any given (lunch)time.

    You're assuming PIDs are randomly handed out. I've debugged enough to notice that given a regular startup, the processes I start in order tend to be within a somewhat predictable range of PIDs. Keep restarting to debug and I get PIDs that are rather close to each other. Is this not the case with the particular OS in the OP?

  • Been a long time since I ran a cron job (unregistered)

    How bad could it really be? It wasn't even kill -9

  • verisimilidude (unregistered)

    I think the lesson here is that when your number is up, you die.

  • John (unregistered) in reply to shinobu

    kill issues the SIGTERM signal by default that can very well be intercepted. kill -KILL sends SIGKILL.

  • (cs) in reply to Nagesh
    Nagesh:
    QJo:
    The real WTF is Turkish pizza, amirite?

    Maybe author want us to goggle for the recipe.

    The goggles! They do nothing!

  • (cs) in reply to Nagesh
    Nagesh:
    QJo:
    The real WTF is Turkish pizza, amirite?

    Maybe author want us to goggle for the recipe.

    I've been on teh internets too long. I googled for "turkish pizza" and was shocked to find that the first page of results were pizzas from Turkey and not shock websites or references to something that gets bold type in the urban dictionary.

  • QJo (unregistered) in reply to Toasty
    Toasty:
    TRWFT is that he thinks a sandwich is healthy.
    :Depends what's in it. If it's a salad sandwich, then yes, that's quite healthy, if you don't overdo the butter and mayo. Putting a hamburger patty inside it, however, reduces its healthiness content considerably.
  • MIKE (unregistered) in reply to EvilSnack
    EvilSnack:
    Captcha: abbas. "The first ABBA was the best. Now we have a bunch of second-rate abbas."

    Can't agree more

    [youtube]_-ErjlR0tbg[/youtube]

  • PC Amok (unregistered)

    Remy's lack of sensitivity to other cultures is just sad. He talks about Turkish pizza and börek as if he wasn't a privileged, white, male, non-geriatric person of pallor.

    CAPTCHA: jugis - There is no right or wrong; just wrong. Can we not escape the white, patriarchy harassment in even a simple CAPTCHA word?!?

  • (cs) in reply to PC Amok
    PC Amok:
    CAPTCHA: jugis - There is no right or wrong; just wrong. Can we not escape the white, patriarchy harassment in even a simple CAPTCHA word?!?
    Right or wrong, thedailywtf-CAPTCHA always has been a sick joke!
  • somewebguy (unregistered)

    I had a fun Cron issue a few months ago,

    I wrote a twitter bot in PHP (Get it over with, I'm a web developer, it's what I know) that grabs the weather from the Yahoo Weather API, and posts the current weather in my city to twitter every time a specific page is loaded.

    I set up cron to access the page every 4 hours, or so I thought, and it would post. Easy enough.

    However, it would post again between 15 to 40 min later.

    Turns out the twitter API wasn't allowing reposts with the exact same tweet. Once the weather changed, it would allow a tweet through. It was calling the page at 12:00, 12:01, 12:02 all the way to 12:59, then waiting until 4:00, 4:01...4:59, etc.

    Changed * */4 * * * to 0 */4 * * * and it works great!

    TL;DR: Sometimes bugs LITERALLY depend on the weather.

  • excellent (unregistered)

    best article in a while :D

  • C-Derb (unregistered) in reply to Fishcake
    Fishcake:
    The WTF is that Steve's Borek was still hot. He'd left the cafe, got back to the office, fixed the issue and it was still piping-hot!
    +1 This line forced me to look up what borek was. I mean, I assumed it was an exaggeration, but I had to be sure.
  • (cs) in reply to GWO
    GWO:
    Chaos Monkey cronscript:

    [ $RANDOM -lt 100 ] && killall mysqld

    Nahh, mysqld kills itself randomly. :)

  • (cs)

    Wait, so you mean that my process won't always have the same ID every time it runs? Well than how am I supposed to know the PID????

  • (cs) in reply to Uli
    Uli:
    The name is Börek, you can't spell turkish food without umlauts.
    Reminder to self: submit brain-teaser to NPR "What do Turkish food, heavy metal music, and lamps from IKEA have in common?"
  • Micky (unregistered)

    Just found that in the HTML code of the article:

    "Astute readers will notice this is an OSX listing of /etc. OSX does not use cron for scheduling, which is why the crontab file is size zero- I touched it just to generate this screenshot, because I was too damn lazy to fire up a VM of a system that actually uses cron."

    Which is, of course, plain wrong. MacOS X does use cron and the crontabs are in /var/at/tabs.

  • Bananas (unregistered) in reply to Charles F.
    Charles F.:
    I know what happened.

    A business manager said, "It's only a matter of time before this application crashes mysteriously," and a development manager wrote it down as a requirement.

    +1

  • jordanm (unregistered) in reply to xaade

    In Linux, PIDs are allocated sequentially. PIDs will not be reused until pid_max is hit and it wraps back around. By default, it will have spawn 32768 processes before it starts back at the lowest unused int. This may seems like a lot, but keep in mind many processes are very short lived and threads are implemented as LWP (light-weight processes) which get allocated a PID.

  • (cs) in reply to C-Derb
    Fishcake:
    The WTF is that Steve's Borek was still hot. He'd left the cafe, got back to the office, fixed the issue and it was still piping-hot!
    +1
  • Bananas (unregistered)

    So, every few days there happens to be a process with PID 21342 alive at 12:22. Chances are it's not the process that's running the critical server program. What then? Weren't there other noticeable odd behaviors on that machine?

    That said, finding that line in the crontab is certainly WTF-worthy!

  • Panda (unregistered)

    I wish I had a roulette wheel that would randomly kill off one of our support reps at our primary vendor.

    Captcha: damnum - as in damn'num to hell!

  • (cs)

    Is there any good reason to ever have a hard-coded PID in a cron job?

  • Captain Oblivious (unregistered) in reply to eViLegion
    eViLegion:
    Remy Porter:
    Lahmacun is not the same thing as Turkish pizza. At least in the Turkish places around here, Turkish pizza is someplace between lahmacun and pide. Admittedly, a subtle distinction, but it's nothing like the traditional lahmacun.

    It's sort of like getting Chinese food in the US. It's nothing like actual Chinese food. While Turkish pizza is closer to actual Turkish food, it's been deeply Americanized.

    Yeah, but calling it turkish pizza is like calling a curry "Indian Stew", because it's been Anglicized. Anyone who does that needs pain.

    Curry isn't an Indian word. Curry is the Anglicized word for 'kari', which means 'sauce' in Tamil.

  • F***-it Fred (unregistered) in reply to Bananas
    Bananas:
    So, every few days there happens to be a process with PID 21342 alive at 12:22. Chances are it's not the process that's running the critical server program. What then? Weren't there other noticeable odd behaviors on that machine?

    That said, finding that line in the crontab is certainly WTF-worthy!

    Probably most days it belonged to a process that had already ended, so nothing happened.

  • Evil (unregistered) in reply to chubertdev

    Yes, a good reason to put a pid in cron is when you want to kill init. Init is always one. How else can disgruntled employees hide their intent?

    Captcha: gravis. What pulls systems down. Anyone remember those game pads?

  • Popeye (unregistered)

    That's an awesome piece of code. I might implement it here ha ha ha!

  • lolatu (unregistered)

    TRWTF is that isn't one of the first things he checked. Whenever a server is acting up you probably want to check the cron tasks to see what, if anything, was running at the time.

  • PG4 (unregistered)

    Just to help some people out. It looks like the person only wanted to do this once. Kill a process around lunch time.

    They didn't know the right way to do it, so they thought of cron. "Hey, I'll just put it in cron, and then sometime later in the day, take it back out of cron."

    TRWTF is that they should have used the "at" command, close cousin of cron which will run a command once "at" a certain time. I've seen people that have "been using UNIX for 20 years", not know about "at".

    The second TRWTF is cron.allow and cron.deny. Any sysadmin should have locked down cron to only accounts have a need for it. A user can't setup a poorly thought out cron job, if they can't use cron.

    I have the second problem right now. A major app that was written long before I showed up at the current gig is a set of cron jobs set to run every few minutes. All the setup and logging overhead of the poorly written scripts just kills the server. If someone had prevented cron from being used for said app, they would have been forced to do things a much better way.

  • (cs) in reply to Captain Oblivious
    Captain Oblivious:
    Curry isn't an Indian word. Curry is the Anglicized word for 'kari', which means 'sauce' in Tamil.

    Yeah, but its irrelevant where a word comes from. What's important is using the word, instead of a description of the thing.

  • Xarthaneon the Unclear (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    shinobu:
    snoofle:
    So did they add a signal handler to log that an external signal requested the application to shut down?
    Nobody can handle SIGKILL, except for Doug McIlroy.
    But even Doug can't handle the consequences of "kill -9 1".

    I don't speak linux commands well - what does that do?

  • Dan (unregistered) in reply to Xarthaneon the Unclear

    Absolutely nothing. Linux protects the init process from userland kills.

  • Steve Holdoway (unregistered) in reply to Xarthaneon the Unclear

    Process 1 is init - the kernel. Kill -9 will terminate your machine with extreme prejudice. Unless you're running DEC Ultrix, where you could run multiple copies. Mind you, the server was unusable...

  • nopony clever (unregistered)

    kill'ing init is just silly because nobody will really do that very often. kill'ing PID 1 is probably more common, but still not something you'd expect to see real often.

    However...

    Several years ago I was sitting in front of a Linux box and suddenly wondered what happens if you try to switch to an invalid runlevel. So I did what anyone would do.

    # init 7

    Give that a try.

    On my system at least, it did what any good program does -- exactly what you told it to. Init killed everything that wasn't supposed to run in runlevel 7 (everything), and I was left only init.

    Oops.

    Even more fun can be had by running killall with no arguments. I think this can vary by system, but I've seen it kill every single process. 

    kill -9 -1
    is even better.

  • DB (unregistered)

    See here's the thing. You're the butterfly fart.

  • (cs) in reply to DB
    DB:
    See here's the thing. You're the butterfly fart.

    Right or wrong, that's just how butterflies propelled themselves back then.

  • (cs) in reply to PC Amok
    PC Amok:
    Remy's lack of sensitivity to other cultures is just sad. He talks about Turkish pizza and börek as if he wasn't a privileged, white, male, non-geriatric person of pallor.

    Did no one else have to Google "borek"? I'd never heard of it before. But I do like baklava which appears to be the desert version.

  • (cs) in reply to Zemm
    Zemm:
    PC Amok:
    Remy's lack of sensitivity to other cultures is just sad. He talks about Turkish pizza and börek as if he wasn't a privileged, white, male, non-geriatric person of pallor.

    Did no one else have to Google "borek"? I'd never heard of it before. But I do like baklava which appears to be the desert version.

    Just a pretentious bloody cheese toastie.

  • np (unregistered) in reply to PG4
    PG4:
    If someone had prevented cron from being used for said app, they would have been forced to do things a much better way.

    Don't be too sure of that. I can imagine them doing things in a much worse way, maybe even poorly reimplementing cron as a php web page...

  • Guru Evi (unregistered) in reply to Lauren

    That is unless it's something like a web service, PHP, Tomcat, Java something that runs itself on cron scripts, something that spawns a lot of processes and doesn't handle the premature death of it's children right...

  • Carl (unregistered)

    I was really expecting this to somehow end with "if it ain't borek, don't fix it".

  • (cs) in reply to John
    John:
    I can see how it could arise.

    Someone is testing the signal handling of a process. It's currently 12:15 and he wants to see what happens if it gets an automated signal from a cron job. His process is already running with a pid of 21342, and so he edits a quick entry into crontab - but then forgets to remove it afterwards.

    Since there were apparently lots of entries there, all essential to the running of the system, when the code was promoted to live, that entry came along too.

    Nah, not buying it.

    Personally, I don't think there is any sensible reason that anyone who understood enough to set this up, could give to explain why they would do such a stupid thing. I'm putting my bet on deliberate sabotage.

    The more I think about the title of this, the more clever I think it is. Nice take on, "A Corny Joke".

  • S (unregistered) in reply to ZoomST
    ZoomST:
    Very believable since most core application behemoths are badly grown apps that will spawn and re-spawn processes as if the server possesses bazillions of processors and memory. And having 1 process killed without notice (not any process) could make the app to go "save everything and close" mode, aka Steve's boss panic.

    Or, depending on the OS in question, the "processes" are actually threads, and a kill signal to the child is handled by the parent...

  • Mickey Blue (unregistered) in reply to shinobu
    shinobu:
    snoofle:
    So did they add a signal handler to log that an external signal requested the application to shut down?
    Nobody can handle SIGKILL, except for Doug McIlroy.
    kill != SIGKILL

    I think kill with no params defaults to SIGTERM on most systems....

    need to explicitly specify SIGKILL(9) if that what you want

  • ohnao (unregistered) in reply to Chad Garrett
    Chad Garrett:
    Watch out for the difference between "turkey" and "Turkey"...

    And FYI, "turkey" is actually named after Turkey: http://en.wikipedia.org/wiki/Turkey_(bird)

    I thought it were the other way around

  • Jim (unregistered) in reply to Coyne
    Coyne:
    John:
    I can see how it could arise.

    Someone is testing the signal handling of a process. It's currently 12:15 and he wants to see what happens if it gets an automated signal from a cron job. His process is already running with a pid of 21342, and so he edits a quick entry into crontab - but then forgets to remove it afterwards.

    Since there were apparently lots of entries there, all essential to the running of the system, when the code was promoted to live, that entry came along too.

    Nah, not buying it.

    Personally, I don't think there is any sensible reason that anyone who understood enough to set this up, could give to explain why they would do such a stupid thing. I'm putting my bet on deliberate sabotage.

    The more I think about the title of this, the more clever I think it is. Nice take on, "A Corny Joke".

    I have met a load of people who can punch out some unix commands without actually understanding what's going on. Some of them are really smart and would shortcut stuff. I can well believe that some of these turkeys would shortcut to the point of hardcoding a pid because they just assume the same program will always get the same pid. Trust me, these people do exist (most of the ones I've met have grown up around C# - or at least windows)

  • (cs) in reply to ohnao
    ohnao:
    Chad Garrett:
    Watch out for the difference between "turkey" and "Turkey"...

    And FYI, "turkey" is actually named after Turkey: http://en.wikipedia.org/wiki/Turkey_(bird)

    I thought it were the other way around
    Nope, it's a law of nature. Name the place first, then name the bird after it. See also "Canary Islands".

Leave a comment on “A Crony Joke”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article