Live data from Hacker News

Ask HN: Best “I brought down production” story?

news.ycombinator.com

101–110 of 301 posts

Re: Ask HN: Best “I brought down production” story?

#101
As an intern at a major automobile parts manufacturer, I took a hub home for a LAN party. Brought the hub back after LAN party and promptly plugged it into a network port and connected the wrong power cable. This was in the server room next to an AS/400 running production.

Took a long vacation weekend as my error proceeded to shut down all production due to network issues causing the AS/400 to freak out.

Cant run a conveyor belt, or robot, or sensor, production line, or or or if your mainframe isn't working.

Re: Ask HN: Best “I brought down production” story?

#102
post #73
post #68

On Linux killall lets you killall all processes matching a name. On Solaris killall kills all processes. To make matters worse, I used the command on a sever with a hung console -- so it didn't apply immediately, but later in the middle of the day the console got unhung and the main database server went down. Explaining that this was an earnest error and not something malicious to the PHBs was somewhat ... delicate.…

Genuine question: what's the usefulness of Solaris' default behavior? Why kill all processes?

I oversaw a Solaris machine for a very short period, and never got any reason to use it. But if you can change the signal, sending SIGHUP into everything looks like reasonable thing to do.

Still, it's not something common enough to deserve it's own program.

Re: Ask HN: Best “I brought down production” story?

#103

I ran a bunch of scripts on some aux boxes, and Tokyo stopped working. Can't talk details... sadly

Reading through these stories, every one of which is fascinating, I’ve never been more glad that my job does not involve doing anything where the consequences could be summed up as “Tokyo stopped working.”

Re: Ask HN: Best “I brought down production” story?

#104
One Tuesday morning, my code brought down 67 restaurants piloting the new point-of-sale (POS) system.

I'd written the code to reformat the mainframe database of menu items, prices, etc, to the format used by the store systems. I hadn't accounted for the notion that the mainframe would run out of disk space. When the communications jobs ran, a flock of 0-byte files were downloaded to the stores. When the POS systems booted with their 0-byte files, they were... confused. As were the restaurant managers. As were the level 1, level 2, vendor, and executive teams back at headquarters. Once we figured it out, we re-spun the files, sent them out, and the stores were back in business. I added a disk space check, and have done much better with checking my return codes ever since.

Re: Ask HN: Best “I brought down production” story?

#105
post #73

Earlier quoted context omitted.

Genuine question: what's the usefulness of Solaris' default behavior? Why kill all processes?

I oversaw a Solaris machine for a very short period, and never got any reason to use it. But if you can change the signal, sending SIGHUP into everything looks like reasonable thing to do. Still, it's not something common enough to deserve it's own program.

Yep, and as weird as killall on solaris is-- the naming of killall on linux is kinda weird. It's "killbyname".

Re: Ask HN: Best “I brought down production” story?

#106
post #90
post #36

Earlier quoted context omitted.

And this is why we use things like database users that don't have delete permission, and row-level security so users can delete things that don't belong to them. I have learned this from a very similar experience.

And why it’s often best to mark a record deleted and then have a reaper remove the records at a later point. But you must make sure all normal queries don’t see deleted items.

That's over engineering. At this point, just rely on PITR. FWIW, postgres does have a "reaper" via vacuum, but not for the purpose of safety. but rather to allow for mvcc.

Re: Ask HN: Best “I brought down production” story?

#107

Not me, but a colleague - he wanted to look around the system as the `uwsgi` user, so he ran `sudo -u wsgi -s /bin/bash`. Except that he typoed, and instead ran `sudo -c wsgi -s /bin/bash`. What that does is instead of launching the (-s)hell as the uwsgi (-u)ser, it interprets the rest as a (-c)ommand. Now, `wsgi` is also a binary, and unfortunately, it does support a `-s` switch. It tries to open a socket at that ad…

Does the proc entry for a running process still link to the now-deleted file in that situation? If so, you might be able to save yourself from a running bash shell by doing a “cat /proc/$$/exe > /bin/bash”

Probably not if it was overwritten (": >/bin/bash") rather than removed and recreated ("rm -f /bin/bash; : >/bin/bash"). The former will cause all processes to see the empty file, the latter would leave processes with access to the old contents.

In this case if you noticed and still had a shell, you could just copy another shell over ("cp /bin/sh /bin/bash"), to at least get back to probably able to login, until you could pull a copy from another machine or backups.

Re: Ask HN: Best “I brought down production” story?

#108
Back in the days of MyISAM and before Google had their own ad network I worked for the world's largest advertising network. It had a global reach of 75%, meaning 3 / 4s of people saw at least one of our ads daily.

I was trying to learn MySQL and the CTO made the mistake of giving me access to the prod database. This huge network that served most of the ads in the world ran off of only two huge servers running in an office outside Los Angeles.

MyISAM uses a read lock on every SELECT query. I did not know this at the time. I was running a number of queries that were trying to pull historical performance data for all our ads across all time. They were taking a long time so I let them run in the background while working on a spreadsheet somewhere else.

A little while later I hear some murmuring. Apparently the whole network was down. The engineering team was frantically trying to find the cause of the problem. Eventually, the CTO approaches my desk. "Were you running some queries on the database?" "Yes." "The query you ran was trying to generate billions of rows of results and locked up the entire database. Roughly three quarters of the ads in the world have been gone for almost two hours."

After the second time I did this, he showed me the MySQL EXPLAIN command and I finally twigged that some kinds of JOINs can go exponential.

Kudos to him for never revoking my access and letting me learn things the hard way. Also, if he worked for me I would have fired him.

Re: Ask HN: Best “I brought down production” story?

#109
I was testing backups for a CMS; to test, I had to destroy the test database. I destroyed the production database. While my manager was querying the CMS to do my annual review.

Good news is I was already planning on restoring the test database from the production backup, so i had the database up in under 45 minutes (slower than it should have been because Oracle's docs were flat out wrong).

A more senior engineer told me he was impressed by how quickly I got things running again; apparently in the Bad Old Days (i.e. a year before I started) the database went down and, while everybody was pretty sure there were backups somewhere, nobody was sure where; customer interactions were tracked by pen and paper for almost 3 business days while this was figured out.

Re: Ask HN: Best “I brought down production” story?

#110
I did the reverse. Using DOS batch scripts I wrote I imported orders twice for a 100 person generic drug company. It was a heavy set of orders as it was. Everyone in the warehouse had to work late that day. Sales guys loved it because it was near the end of the month. No one at the company seemed to mind the mistake. I was mystified that I did not get in trouble. They had tight relationships with thier customers and just shipped less over the next month.
Post reply on HN