• Flashx11 (unregistered)

    (laughs) Wow. That's really funny.

  • Bozo (unregistered) in reply to Pelle

    Yeah and what happens if that computer died?

    Hoping that all the doors magically opened rather then magically shut ;p

    that would kinda suck in an emergency

  • Bozo (unregistered) in reply to OzPeter
    OzPeter:
    For changing a critical piece of security infrastructure with out any authorization or approval? I don't see him as a hero but as more of a vigilante.

    A hero would have done an investigation without changing anything and then made a clear and precise report the next day as to what was causing the heartache. At which point a considered response could be made which took the overall situation into account. After all he was new there, so there is no way that he would have been able to take the entire companies position into consideration.

    In fact he did not actually change anything, all he did was fix a symptom. I would guess that as the current log file filled up the system would start to behave in the same way again. So all he achieved was to give himself a virtual wank and a smug look when his coworkers next discussed the improved performance.

    Just reading that makes me want to karate chop you in the mouth

  • (cs) in reply to Stu
    Stu:
    The last company I worked for was very hot on timekeeping - no flexibility was allowed - and hence people generally arrived at 8:58 and left at 5:32. Unfortunately, it was discovered that the swipe card system only had limited resolution on the time, and the time was used as primary key in the database. Swipe in too soon after someone, and you wouldn't be logged, and hence you'd receive an email from HR.

    Once that was discovered, a new company policy was instituted - wait five seconds after the last person. Hence at five to nine there would be a nice queue of coders, any one of whom could have fixed the real issue, counting "one elephant...two elephant...five...swipe" under their breath.

    Brillant!

    This is the first time that I've heard of management (almost literally) ignoring the (five) elephants in the room...

  • Northerner (unregistered) in reply to OzPeter

    And after reporting the issue, that would be the end of it. Sounds like this guy wanted something radical, something out-of-the-box, something useful, like ACTUALLY FIXING THE PROBLEM.

    After his precise report, if anyone paid any attention to it at all, someone would see a chance to make someone else look bad, take it, block that someone's attempts to fix the problem, get in a big HR snarl over it, etc etc. Leaving the ancient system with its major security problem in place, and not getting anything accomplished at all.

    The best solutions are the ones Management doesn't meddle to death.

  • tinkerghost (unregistered) in reply to ya

    One company I worked for had RF badges that auto opened the doors as you approached - unless the power was out, then the doors auto-locked & wouldn't open at all. Per management, that was OK because if the power went out in a fire, you could get a stool & break the glass.

  • (cs)

    Really good story. I wonder if it will happen again?

  • Chris M. (unregistered) in reply to DOA
    DOA:
    I must be missing something. If the system was still processing swipes from yesterday, how come people were still able to use the doors. Wouldn't they have to wait a day for their swipe to open the door? Or did the system pick random swipes and process them? In which case wtf kind of queueing system is this?

    What you're missing is that people weren't entering on their own swipes. You swipe, waiting a random amount of time, and the door unlocks. But it's not unlocking on your swipe, it's unlocking on somebody else's swipe from 12 hours ago. In fact, the door would've unlocked if you'd never swiped at all, as demonstrated by our hero listening to the doors unlocking themselves after everybody's gone home.

  • Daniel Howard (unregistered) in reply to Chez

    The fact that the rename immediately fixed the problem is also a clue: instead of keeping the filehandle open and appending, eavh swipe required the file to be opened, seek to the end, then append.

    -daniel

  • katie (unregistered)

    great story :) http://katie.blogsite.org

  • Mary Poppin' Caps (unregistered)

    Sometimes, while my wife is sleeping, I scratch my anus and stick my finger in her mouth.

  • cloud9ine (unregistered) in reply to Chez

    You beat me to the answer.

    I use a serial port sniffer program which logs data, identifies packets, and creates a logfile. As the logfile gets bigger, the sniffer has trouble turning around and completing packet identification to match the speed of data.

  • Robert (unregistered)

    Dear Ghod is there a programmer in the house! (Well maybe cloud9ine is)

    Here's how it works...

    There are a few doors connected by serial lines to the box; they're all used frequently.

    The box has a process/service that collects messages from the doors and puts them into a queue, as the message is received it's displayed in the monitor window. This process has to be ready to get a message at any time, it cannot block waiting on disks or GUIs because it would lose messages.

    The second process reads a message from the queue and validates it against any weird rules, maybe print out a log message, appends the message to the log file and sends an 'open the door for a few seconds' message to the right door. None of these jobs should take very long but any of them may take long enough to lose a message from another door.

    The problem is that it's taking longer to write the message to the log file than the average time between messages; it looks like a LOT longer. With the multi-swipers the average message time might be as short as a second or two. This causes the queue to build up during the day with all the doors opening in random fashion every few seconds in random order. The queue gets shorter overnight but not enough to clear it; only over the weekend does it clear. A multi-swiper will case one of the doors to be sent multiple opens and the rest to be left locked for a minute or two, but these responses often happen hours after the swipes.

    Why isn't the logfile being cleared? Because the person who used to move it into a CSV or print it out left the company, nobody else was interested in the reports so the logfile was never moved and so just built up.

    If no one wanted the log file it "should have been" turned off but no one cared.

    The only problem with the machine was assuming the user would want the logs or turn them off rather than doing a time based log rotation. But that's hardly a WTF.

    I'd say Why-TF didn't somebody do something before if I hadn't heard of PHBs.

  • Random (unregistered)

    i'd like to point something out. the typical office is open from ~6AM to ~9 PM.. that means for about 9 hours, there would be no swipes. so once in awhile, when the employees swiped their cards, they'd have to wait 9 hours for the door to open? i don't believe this story.

  • Chad (unregistered) in reply to Jeroen

    That makes no sense. Because then if you went to a door that is almost never opened and swiped your card, it would take hours to open, not an extra 5 min. I see where you came to that conclusion, but this system is obviously more complicated, and yet still faulty. A simple fix would be to write some code to store seperate logs per day. Obviously when the new log fills up the same thing is going to happen.

  • LAR (unregistered) in reply to OzPeter

    Chicken

  • (cs)

    The The True WTF here is that the server that controled the door locks for the office wasn't physicaly locked up and apparntly from the description the OS was logged in and open to anybody to do anything they wanted. This means anybody could have gotten into anything.

  • Nick J (unregistered)

    Is this a repeat? It seems familiar somehow...

  • HTMLCODER.exe (unregistered)

    I was having fun with Unix "cat" command, and set it up so it doubled the filesize of an input file. Just after a few [ENTER]'s it was about 190 MB large, I noticed it lagged the terminal. Now, I booted Windoze, and opened the file. My system hanged. And I have a 1GB PC! //By the way, Notepad has a 10MB limit on files. //Unfortunately, it first opens the file, and only //then it throws an error incase 10MB < filesize.

  • Ken (unregistered) in reply to OzPeter

    So I see OzPeter either being an idiotic PHB, or trolling...

    I also see almost all of you not having any clue how this system actually works and/or refusing to believe the story because of this. The logfile is a logfile, not a queue of doors to open... it's just that writing to the logfile is done in the same thread as sending lock/unlock commands and receiving card swipe information. In fact it's probably in a while(1) loop or similar. I've written software with this problem before... luckily I tried it with a large file and then realized I should probably be (a) writing a log rotation script and (b) using append mode. PS: if you're rotating logs and using any of several common filesystems, you may still run into a performance issue within the filesystem itself if you put all the old logs in the same directory. I created a structure like so to avoid this problem:

    • directory structure root ->year -->month --->actual daily log files.

    FYI - most doors like this lock from the OUTSIDE, and have what's called a "crash bar" on the inside that will unlock the door whether it's locked or not. Those of you screaming OMG FIRE HAZARD should probably, like, actually look at a door in a large commercial/corporate building before posting.

    As usual when reading this site or Slashdot, I find myself reading the comments with a single thought running through the back of my mind... "why the HELL am I reading user comments again? WHY? WHY?!"

    Ron:
    Funny swipe card system story.

    I used to go to a really high tech university. In fact the name of the school ended in "Institute of Technology". Yeah, that one.

    They had this fancy key card system on all the buildings, so that only students with cards were allowed to enter the buildings.

    They also had a really comprehensive disability policy, which stated that all buildings must be wheelchair-accessible. So every building had a handicap button outside every door, which, when pressed, would immediately open up the doors.

    Yes, completely bypassing the keycard check.

    Yes, everyone knew about it.

    As far as I know, it's still there. It still worked when I visited the campus 4 years after I left.

    hahaha, we had that at WPI too for a while. Then campus police watched six people use it in a row and realized something was fishy. It was fixed two days later and I couldn't take shortcuts through Daniels Hall and Fuller Labs on my way home from work anymore :(

  • Dave (unregistered)

    This illustrates why the logging server should always be separate from the validation server. (There are LOTS of reasons why it should be so, but this is an illustration of why you really, REALLY cannot merge them and not get stupid results.)

    captcha: vulputate

    (Doesn't that sound like something they do in furry fandom?)

  • Jim Smith (unregistered)

    Two lessons:

    1. Seize authority
    2. When in doubt - delete
  • Stefan (unregistered)

    Very funny. I'll make a short film out of this, problem is not a lot of viewers will understand it. ;)

  • Anonymous (unregistered)

    Jeremy would be a boss if he could write a shell script to copy and rename backups of the log once every few months or so it never happens again.

  • unsprung (unregistered)

    This is still my favourite story of all time. Comedy + valuable lesson = gold.

  • steve (unregistered)

    There are a handful of things here that nobody else has mentioned.

    First of all, what everyone has forgotten is that the door is supposed to lock behind you. You swipe, it unlocks, it waits several seconds, and it locks again. If this feature were poorly designed, it could easily have caused the bizarre behavior.

    Secondly, the log file wasn't. Wasn't a log file, at least, wasn't just a log file. When he renamed it, all of the doors suddenly locked - obviously the system was using the log file to determine which doors should still be unlocked. It was an input file in addition to a log file.

    Another thing - when it was backlogged, swipes appeared in the log file long before the system processed them. Apparently the log file was the queue (again, actually an input file rather than merely a log). Which means that the application had to keep track of which line on the log file was next to process - and from the slowness, it was probably reading the entire log file up to the next line to be processed.

  • Rocky (unregistered)

    Would be great to invite Michael Stevens to that office to analyse the behaviour of those employees: https://www.youtube.com/watch?v=BR-eMMCp7tg :D

Leave a comment on “The Haunted Door”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article