- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Perhaps it was a good computer-oriented anecdote, but how is this worse than failure? Or what the fuck? Or whatever this site is about?
Admin
Typo: In the second-last paragraph, the doors started out locked, then he unlocked one of them. The next sentence says "unlocked" again—it should say "locked."
Admin
The story reminds me a bit the way its comments behave. Even though the answers are given already, even an hour later the same questions are still asked again ...
... and again ...
... and again ...
... mindlessly clicking away into oblivion ...
spooky...
Admin
"Life was good for Jeremy... His cubicle was..."
Spot the WTF!!! we're people, not battery hens. I don't see how anyone can consider working in a cubicle far "good".
Admin
The other other real WTF is that Full Sail has an airplane rather than a sailboat in its logo.
--RA
Admin
At first, I was waiting for him to find out that the door was being opened manually by some person in some closet somewhere whenever he saw that someone swiped a card.
Admin
flush isn't only something you do to a toilet...
Admin
I was waiting for him to find a control system of some sort that was just randomly opening doors in the hope someone was there
Admin
Thumbs up. Suspense, mystery, well-written and a nice relief at the end. One of the nicer WTF's; it somehow has the same kind of charm as ITAPPMONROBOT.
Admin
The real WTF is that the door security is on an unlocked terminal that any scmuck can walk up to and monkey around with.
Admin
They WERE queued, but there should never have BEEN queueing.
The delay built up from having to both read the now-enormous log AND all the swipes.
Admin
I love the mysticism and magical thinking that grew up around the doors operation. Next thing they would have been sacrifing goats to open the lock.
Admin
This is why logfile rotation was invented.
Even without rotation though, this should not really have been a problem unless some really stupid code was involved (e.g. rewriting the logfile completely each time a line was appended). That code is probably a real WTF.
(And, I can't help but wonder...if they can't manage to get something like that right, what about the actual security of the system...)
Admin
Admin
I bet it was Irish Girl opening and closing the door all night.
Admin
So you could have got through the door by just standing there and waiting, heh :)
Good article!
Admin
Exactly my thought. If the door is pissed off at you, you'll wait up to a minute, but if the door really, really likes you, by having read you mind, it'll open before you swipe the card.
Admin
Now, THAT's what I call a real WTF!
Admin
Admin
Its called job security. He will have to go in once a week and manually rename the log - for life.
Admin
This brings to mind a story a friend told me about a card swipe lock at the bank he works at. For aesthetic purposes the door was one huge piece of glass held shut by a magnet. One day the system stopped working entirely. The downtime was sufficiently long to allow for someone to eventually figure out that the door could be opened simply by jerking on it hard enough to overcome the force of the magnet. This solution was good enough for them so they continued to use it until the door shattered.
Admin
For someone like me working in a room of 30 people sitting shoulder to shoulder time-life operator style, a cubicle would be bliss.
Admin
It can't be randomly processing yesterday's clicks, otherwise everybody would suffer a "bad case of the Mondays."
Admin
It can't be randomly processing yesterday's clicks, otherwise everybody would suffer a "bad case of the Mondays."
Admin
Nah, this is nonsense. If you leave the access-controlling pc in an unlocked cupboard and without cumbersome passwords an' newfangled thingsies, then you haven't heard of the word "security". A new employee, or cleaner, can just access it and change privileges etc at will? Or change the accesslog to hide anything?
I can't really believe the hypothesis that the unlocking is in response to requests made 24hours earlier: the requests would not spread evenly enough to let access be between 10 and 60 seconds, that just doesn't make sense. There must be a way that e.g. 1 request in 5 is honoured and the rest put in backlog (an advantage to the multi-swipers), or only one request per minute per door or so?
Admin
In case of the door unlocking just before they went to swipe the card, they probably assumed that it was from somebody else that swiped a few minutes ago, got bored, and went somewhere else.
Or they assumed it was the ghost of Irish girl I guess.
Admin
I expect when the thing was first installed many years ago the tech person explained to the manager that the log would have to be archived regularly. The manager probably nodded and made a mental note to ask somebody wtf "archiving" means and then, went out to lunch. Hence it never actually happened.
Admin
I had a similar experience some years back: we were demoing a document management application using SQL Server. We were thourough in our preparation and made sure that our laptops were sized and configured correctly and that we went through all the features that were to be demonstrated, several times.
Came the demo, the system was too slow to even go through the features we wanted to show. Back at the office, we had the usual finger-pointing exercise, which ended up blaming M$ and their half-baked rdbms...
Then, we started looking a bit deeper and found out that the logs were eating over 100 mb, due to all the prep we did before the demo. Nobody had tought of cleaning them.
Lesson learned: blame M$, you'll always find a way to tweak the issues so that they end up being the culprits.
Admin
Is firing the worst thing that can happen to you? Is getting fired for solving a problem the worst thing that can happen to you?
Grow a spine. Take some initiative. Any company that wants to fire somebody for simultaneously fixing a problem and improving security throughout the company is not a place I'd like to be working.
Read this, and be enlightened: http://www.siliconhell.com/madcat/cathumour/sparrow.htm
Admin
/dev/null
Admin
Eh, I call shenanigans. If it really was still queuing swipes from the day before, what do people do on Monday? Wait a few hours to get into the building? If someone's not there for a couple days and come back to their office, do they swipe, walk away for lunch, and come back just in time to get in? Something here doesn't add up.
What I can see happening is it being quick in the morning, when there's nothing in the queue, and slowly building up over the course of a single day when people swipe their card 20 times in 15 seconds waiting for their swipe to be processed. But in that case, there wouldn't be enough of a backlog to be constantly unlocking the door that J heard...I don't know. Something just seems odd about this one. The convenience factor of "Someone wants to get into room, and within 1-2 minutes, the queue just happens to get to a point where that door opens, and this happens so often that no one thinks anything of it except 'Hm, delay.'" is almost off the scale.
Admin
My guess is that there was a roughly constant one minute delay on processing any swipe, thanks to stupid processing of the log file. Swiping a lot would cause the door to lock and unlock about once a minute until the number of swipes had happened. With so many people using the door and getting pissed at the one minute delay and swiping a lot, it got to a queue over a day long. If it unlocked in less than a minute then it was responding to someone else's swipe from earlier.
Over the weekend it would catch up again and take a minute to respond to the first person arriving to work on Monday. This would be longer than when the queue was backlogged (which would average 30 seconds), so they would definitely swipe several times to be sure, and set the whole thing going again.
Admin
When I was an intern, I sat in a secured area that was used for presentations. I could look out the big windows of the presentation room and see the front door. There was this one woman who would forget to swipe her badge at least once a week. She would just walk up to the door and jerk on it, then turn around and swipe her badge. One day their was a problem with the security system so they unlocked all the main doors and had security guards checking badges. She walked up and pulled on the door, which opened, then she turned around and swiped her badge before coming in. The security guards were in the reception area (which she couldn't see from the doors). I never figured out what the hell was wrong with her but it was fun to bet on whether she would remember to swipe or not.
Admin
Do you think the computer processing the swipes goes home for the weekend too? It is sitting there catching up on old swipes.
By the time people come in on Monday, the queue has dwindled so their swipes process. Eventually there are more people than the computer can handle and it gets backed up again.
Just think of it as a FIFO queue.
Admin
It's clearly a WTF in either sense.
Posit a requirement: "We need to queue up access requests (on one or many doors). Read off queue, unlock door, lock door, and read off queue again. We also need a log for compliance with Fed-U-Loathe regs."
(It's a silly requirement, but I expect the original was something like this.)
Now posit a developer whose brain is not yet fried. Why would you want the queue file to be the same as the log file? What possible purpose could that serve?
And, to make it worse, the app clearly opens the log file, scans to the end, and does some fancy timestamp-based stuff (ignoring the fact that the request came from fifteen hours ago -- hell, these drones must be really patient queuers) and then closes the file. No fseek, no ftell, nothing remotely sophisticated like that: nosir.
At this point I respectfully request permission to interject "WTF?"
It's just as well that Jeremy worked out what was going on before the stupid thing ran out of disk space and locked the building down forever.
So, the real WTF (ta-da!) is ... MS access.
Er ... log.txt
Admin
Perhaps it's, oh I don't know... A curious perversion in information technology.
Admin
He sooo should have set it up so that the insane clattering of locks happened about an hour after everyone had arrived for the day...
Admin
OxPeter If you have pointy hair, I'm pretty sure I used to work for you. Thank goodness I don't anymore.
Admin
The cue file may not have been the same as the log file. It's likely incoming swipes would be added to a cue. Separate thread would do something like:
Accept incoming swipe, Authenticate, Open Log, Read Log, Save to Log, Open Door.
which would stop the door being opened until it was logged.
Otherwise, the door would open and it may not be logged. If you could get the computer / app to crash quick enough, you could get in completely unlogged, so it's better to log it then open the door.
Admin
Would be fun to go swipe a invalid card a zillion times... People swiping their valid card the next day would think they where blocked :D
Admin
I know...this is a fun game of mine now. I actually come into these response strings and do a search on "irish" just to see all the fun posts. It's almost more fun than the on-topic discussions.
Admin
Yeah. I really expected to find out that a receptionist was notified at every swipe and manually logged the ID and pressed a button to unlock the door, and had set up some timed method for pressing the button after hours.
Admin
thats a fire hazard
Admin
What confuses me is that this log file is only queued up from 8am the previous morning, not for years and years. We can therefore infer that the file is not logging historic swipes - it is acting as a holding place for swipes to be processed (so the filename is a bit of a wft anyway). The only architecture I can make out that would allow this is if the swipe system and the lock system are separate - the swipe card reader reads the swipe, opens the file and appends the swipe details to the logfile. The lock system then opens the file, reads the first line of the text file and if the swipe card number is allowed access it unlocks the door.
Presumably there was a time when the system was new and the user numbers were small when this worked fine and there was never more than one or two numbers in the logfile queue.
Then at some point, the unlocking service hung. The service was eventually restarted, but by that time the damage was done! The swipe reading service had been dutifully logging swipes for hours, and the file had grown too large! No longer could the locking service keep up, and the doors unlocked at random as old swipes were processed.
Of course, if I'm right then Jeremey will have fixed the problem, becuase if swipes are being processed almost instantly the queu file should not be able to fill up again.
All seems a bit unlikely though, doesn't it - I'm inclined to call a certain degree of shenanigans!
Admin
Admin
I had an account that I supported that had an application that ran all day. As it got later and later the application got slower and slower. They called me in to see if I could see anything that could explain the problem. I found that the application opened a dated logfile, appended a record and closed the file for each transaction. As the file grew each attempt to append to it required reading the entire file to find the end. Since many people ran the application, a redesign writing through shared memory to a separate process would be possible but not something that anyone wanted to deal with. I realized that the first time that the application ran each day it tried to open a logfile with the current date. When it didn’t find the file it created one. The default file type was a plain sequential file. I took five minutes to write a command file that would create a dynamic access file every day at midnight. The dynamic access file looked like a sequential file but also contained a table whose entries pointed to the beginning of each record in the file. When the program appended to the dynamic file the file system knew where the end of file was and the application never slowed down.
Admin
100 Mb? That's nothing.
Oracle's OPMN logs by default grow to about 1.6 Gb each before rotating. And old log files never die, they just fill up your file system.
Admin
Eh, sometimes life requires direct action. By merely renaming the log, he actually was playing it safe.
The fact that it was so neglected tells me that, had a report been done up, there'd be no one to give it to. Some alarm system vendor installed the system, management signed off on it, whoever was originally trained on it left the company, and it was left to rot. Except for the exciting day when someone said, hey, let's build a cabinet around this so we don't have to look it.
No mention of passwords. Not even a lock on the cabinet. People complaining and still no one was called in to look at it. If they didn't care enough to keep it working, why would they suddenly get up in arms about security?
(OK, besides the fact that managers, as a species, are famouse for having such moodswings :D )
I'm willing to bet that, had Jeremy/Justin owned up to his deeds, the only bad thing to happen would be the AC system would now become his responsibility...
Admin
At a place where I used to work, the magnets holding the doors closed for the security system were getting a little old and tired, or something. Anyway, someone discovered that with a little force you could just yank the door open and not bother with the swipe card.
This went on for a few weeks, until it was noticed and an angry email went round from the person responsible for security, saying that we were damaging the system.
My response, pointing out that a security door that could be pulled open by hand was worse than failure, and that the sooner we properly broke the existing doors so it could be replaced the better, and therefore we were doing him a favour, was not well recieved.
Admin
This doesn't add up at all. No one noticed doors locking and unlocking all the time? If the delay was measured in days, or even hours, people would notice right away. If you ever were the first to open a door in a day, it would take hours for it to unlock.
It makes more sense for the queue delay to have been 15-60 seconds, depending on the current demand for unlocking. Something more probably went wrong that night to cause the door to keep locking and unlocking.