71–80 of 85 posts
Unix one-liner to kill a hanging Firefox process:
http://jugad2.blogspot.in/2008/09/unix-one-liner-to-kill-han...
It had an interesting thread of comments in which both others and I participated, and at least I learnt some things.
I think caution is still key, if you don't know what's going on Slow is Fast here. Several years ago while I was on an airplane flying to spend a nice vacation break with my family my admin partner tried to shutdown a MySQL db the "right way". He logged in and ran a mysqladmin shutdown and waited for a while. Not sure how long he waited but he claimed it was a "long time". Since it felt like there was no response to…
The advice about Slow is Fast in such situations is spot on.
Reminds me of a Unix incident at an automobile component manufacturer's plant. They had a multi-user Unix box supplied by the company I worked for at the time - a large Unix hardware and software vendor. A colleague and I had gone there for some system maintenance. In order to do something, my colleague, before I could stop him, gave the command "init 0" on the root console. ("init 0" shuts the system down without confirmation, for those who don't know, if run as superuser.) Within seconds the phone in the computer room was ringing madly, with calls from different intercoms on the shop floor, inventory store, etc. He had to apologize to many of them before they calmed down ...
I think caution is still key, if you don't know what's going on Slow is Fast here. Several years ago while I was on an airplane flying to spend a nice vacation break with my family my admin partner tried to shutdown a MySQL db the "right way". He logged in and ran a mysqladmin shutdown and waited for a while. Not sure how long he waited but he claimed it was a "long time". Since it felt like there was no response to…
The only reason I can think of to shutdown a production SQL database would be to do maintenance. In which case any sane admin should be taking a backup in advance. That should be the first step.
If the database is not a production server, does it matter if data was lost?
If the production database crashed/bugged out and therefore needed to be halted, was it really ready for production in the first place?
I don't mean to offend, but it sounds like your partner is a bit of a doofus.
I think caution is still key, if you don't know what's going on Slow is Fast here. Several years ago while I was on an airplane flying to spend a nice vacation break with my family my admin partner tried to shutdown a MySQL db the "right way". He logged in and ran a mysqladmin shutdown and waited for a while. Not sure how long he waited but he claimed it was a "long time". Since it felt like there was no response to…
I'm aware it may be an irritating question to answer, and I'd understand if you don't bother, but I have to ask it because I did never understand why people do such things... Was the extra performance in any way worth it?
Sadly it worked very well except when people used a big hammer on it. We had replication slaves but in this incident the salves were not replicating and somehow the script checking them wasn't alerting. But even so the admin didn't check before bashing the keyboard and thus we were left with manual reconstruction from backups and other sundry sources of information.
Earlier quoted context omitted.
I'm aware it may be an irritating question to answer, and I'd understand if you don't bother, but I have to ask it because I did never understand why people do such things... Was the extra performance in any way worth it?
Here's another question some will surely find irritating: why would you take your laptop and work phone on "vacation"?
I can go on for hours about those two words, everyone wants to be their own boss until they don't want to be... :-)
Earlier quoted context omitted.
You, and the OP, are likely mistaken about the cause of the corruption. MySQL, running InnoDB, is ACID compliant. InnoDB takes that durability seriously, and even by hand-tuning the performance factors, it's very hard to put InnoDB in a state where a simple process death, even during shutdown, will corrupt the files on disk. If the database truly corrupted only due to improper shutdown, it was because the double writ…
> double write buffers were disabled on a non-atomic FS Surely just sending SIGKILL will allow the writes already issued to complete, regardless of the FS type/options? Nobody kicked the plug out of the wall.
InnoDB writes to the doublewrite buffer (an internal tablespace on disk), then the record in place. If the two do not match on recovery, the record is considered not written, and rebuilt from the transaction log.
If the doublewrite buffer is disabled, then InnoDB has no way of telling if the write to the page on disk was started, completed, or partially completed. This causes corruption.
I think caution is still key, if you don't know what's going on Slow is Fast here. Several years ago while I was on an airplane flying to spend a nice vacation break with my family my admin partner tried to shutdown a MySQL db the "right way". He logged in and ran a mysqladmin shutdown and waited for a while. Not sure how long he waited but he claimed it was a "long time". Since it felt like there was no response to…
That seems like a strange anecdote to me. The only reason I can think of to shutdown a production SQL database would be to do maintenance. In which case any sane admin should be taking a backup in advance. That should be the first step. If the database is not a production server, does it matter if data was lost? If the production database crashed/bugged out and therefore needed to be halted, was it really ready for p…
The core issue was actually a deadlock but he wasn't trained in detecting that and in the past just restarting the db "fixed it". Because of course all the sessions dropped and dead locks were resolved.
This was very much a high visibility production environment and yes we all make mistakes sometimes.. How else can we learn.. Trust me he never did that again! :-)
Remember, all of use were a doofus at one time and even worse many of us are every day.
It matters very little to me how people screw up, it matters how they recover, learn and avoid doing it again in the future.
My favorite saying "Originality in mistakes" if you're going to screw up make it big, creative and interesting. And please, don't repeat it.
Earlier quoted context omitted.
My apologies if it sounded like I was doubting that there was corruption - I was not. I was doubting that merely sending kill -9 to the process was the sole cause of the corruption. More than likely it uncovered the corruption due to having to do recovery against corrupted data.
In the postmortem it seemed that by issuing the shutdown but not waiting for it to complete the database ended up in a strange state that we could never fully recover from. I guess the moral here is tread lightly and take the time to be informed before you just smack something with a club.
Earlier quoted context omitted.
Earlier implementations of the Unix kill command did not allow names, only numbers, so many people (deeply familiar with Unix) know the numbers as well as or better than the names. Plus, it's shorter.
What earlier implementations? The initial import of /bin/kill into the NetBSD source-tree accepted signal names and that was 21 years and 2 months ago. Same with FreeBSD and their commit message even implies that signal names were allowed in the original 4.4BSD-Lite source. WRT shorter: Magic numbers don't just suck in programming.
7th Edition AT&T Unix did not allow signal names (http://plan9.bell-labs.com/7thEdMan/v7vol1.pdf, search for "extreme prejudice" -- I still remember many of the little gags in the early manpages).
That was a mainstream release in the mid-1980s. Even the basic utilities like kill(1) were incompatible back then, so if you worked on both BSD and AT&T systems, it was easier to use the compatible subset.
*
Regarding magic numbers: in general, yes, to be avoided. But my usual use of kill -9 is in exasperation, from the command line, and clarity for others is not a priority. I admit, in a script, kill -HUP is to be preferred to kill -1. But even in a script, I'd say kill -9. This usage thing seems to be complex.