tkuchikiの日記

新ブログ https://blog.tkuchiki.net

bash で特定のコマンドを実行前にキャンセルする

bash trap

DEBUG を trap すれば、コマンド実行前に任意の処理を挟めるということがわかったので、特定のコマンドが入力されたらキャンセルできないか試してみました。

COMMANDS=$(cat <<EOC
rm -rf /tmp/foobar
EOC
)

preexec() {
    [ -n "${COMP_LINE}" ] && return
    [ "${BASH_COMMAND}" = "${PROMPT_COMMAND}" ] && return
    local cmd_history=$(HISTTIMEFORMAT='%F %T%z ' history 1)
    #local cmdtime=$(date -d "$(echo ${cmd_history} | perl -lane 'print join(" ", @F[1 .. 2]);')" +%s)
    local cmd=$(echo ${cmd_history} | perl -lane 'print join(" ", @F[3 .. $#F]);')
    [ "${cmd}" = "" ] && return
    cancel "${cmd}"
}

cancel() {
    local cmd="${1}"
    IFS=$'\n'
    for cancel_cmd in $(echo ${COMMANDS}); do
        echo $cmd | grep -qs "${cancel_cmd}" && echo "cancelled ${cmd}" && kill -INT 0
    done
}

trap - DEBUG
trap 'preexec' DEBUG

上記を .bash_profile か .bashrc に書いておいて以下のようにコマンドを実行すると、

$ mkdir /tmp/foobar
$ rm -rf /tmp/foobar
cancelled rm -rf /tmp/foobar

$ test -d /tmp/foobar
$ echo $?
0

mkdir /tmp/foobar は実行できていて、 rm -rf /tmp/foobar はキャンセルできています。
ただし、これだとコマンドの引数の順番が違うとだめになってしまうので、sort して順番を揃えたほうが良さそうです。

tkuchiki.hatenablog.com

では、CentOS6 だとだめでしたが、これを応用すると CentOS6 でも HISTFILE にコマンドの履歴を残しつつ、history を消すことができました。
zsh には preexec hook という機能があるそうなので、trap ではなくそちらを使うと良いようです。

この設定が安全かどうかは確認できていないのでご利用の際はご注意ください(使う人いないと思いますが)。

参考

bash の history からコマンドを実行できなくする & コマンドの履歴は見られるようにする設定

bash history

bash で以前実行したコマンドを ↑ キーや Ctrl+p、Ctrl+r で検索すると思います。
このとき、

  • 以前実行したコマンドの引数を一部変えて実行したいから history からコマンドを探して一部だけ書き換えようと思っていたのに間違えて Enter を押してそのまま実行してしまった
  • ↑ キーや Ctrl+p で履歴を辿っている途中に間違ったコマンドを実行してしまった

などのオペレーションミスをしたことがある方、いらっしゃると思います(ローカル環境とリモート環境を行ったり来たりしているとミスしがちな気がします)。
history を保存しないようにすれば(set +o history など)上記のようなオペレーションミスは防げそうですが、コマンドの履歴が見られないのは不便です。
そこで、history からコマンドを実行できなくしつつ、コマンドの履歴は見られるようにする設定を検証しました。
検証環境は

- GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu) # Amazon Linux 2016.03, 2016.09, CentOS 7
- GNU bash, version 4.3.30(1)-release (x86_64-pc-linux-gnu) # Debian 8.5

です。
CentOS6 の GNU bash, version 4.1.2(2)-release (x86_64-redhat-linux-gnu) では動作しませんでした…

#export HISTTIMEFORMAT='%FT%T%z '
#export HISTFILE=/path/to/.bash_history
shopt -u histappend
export PROMPT_COMMAND='history -a; history -c;'

PROMPT_COMMAND を使ってコマンド実行後に history -a でコマンドの履歴を HISTFILE に追記し、 history -c で history を削除しています。
history -a で追記しているので histappend は無効にしています。
時間を記録しなくてよければ HISTTIMEFORMAT は設定不要ですし、HISTFILE もデフォルトの設定で良ければ書く必要はないです。
この設定をした状態でコマンドを実行すると HISTFILE には保存されつつ、↑キーなどでコマンドを探すことはできなくなります。
コマンドの履歴を見たいときは HISTFILE を直接見れば OK です。
ただし、!! や !$ のような直前のコマンドや引数を参照する機能は使えなくなりますので注意してください。

おまけ

HISTTIMEFORMAT を指定した状態の HISTFILE は以下のようになります。

$ cat $HISTFILE
#1488171696
ls
#1488171701
echo foo

これだとちょっと読みにくいので整形する関数を用意しておくと便利です。

read_history() {
    awk 'NR % 2 { gsub("#", "", $0); t=strftime("%FT%T%z", $0); next } {print t, $0}' $HISTFILE
}

read_history を実行すると以下のようになります。

2017-02-27T05:01:36+0000 ls
2017-02-27T05:01:41+0000 echo foo

読みやすくはなりましたが、毎回 grep したりするのは面倒なので peco を使っていい感じに見られるようにしてみます。

peco_history() {
    awk 'NR % 2 { gsub("#", "", $0); t=strftime("%FT%T%z", $0); next } {print t, $0}' $HISTFILE | peco
}

bind -x '"\C-r": peco_history'

これで Ctrl-r でコマンドの履歴が見られるようになります。

追記

※追記1 2017/03/01 16:38

tkuchiki.hatenablog.com

DEBUG を trap すれば CentOS6 でも似たようなことはできました。

※追記2 2017/03/01 18:50

この機能が欲しいと思ったことはないけど、履歴を書き出すときに先頭に # を追加してコメント化して保存するのではダメなんだろうか。 - n314 のコメント / はてなブックマーク
というコメントをいただいたので、

bash で特定のコマンドを実行前にキャンセルする - tkuchikiの日記

のように DEBUG を trap して # を追加するのを試してみました。
preexec でコマンドを HISTFILE に書き出すときに # を先頭につけて history -r で HISTFILE を history に読み込むようにしたらできました。

preexec() {
    [ -n "${COMP_LINE}" ] && return
    [ "${BASH_COMMAND}" = "${PROMPT_COMMAND}" ] && return
    local cmd_history=$(HISTTIMEFORMAT='%F %T%z ' history 1)
    #local cmdtime=$(date -d "$(echo ${cmd_history} | perl -lane 'print join(" ", @F[1 .. 2]);')" +%s)
    local cmd=$(echo ${cmd_history} | perl -lane 'print join(" ", @F[3 .. $#F]);')
    [ "${cmd}" = "" ] && return
    (echo "#${cmdtime}" ; echo "#${cmd}") >> $HISTFILE
    history -r $HISTFILE
}

(もしかして、こんなめんどくさいことしなくてもできる？)

RDS for MySQL と Amazon Aurora でクエリによる取得行数を取得するなら SHOW GLOBAL STATUS WHERE variable_name = 'Innodb_rows_read' を使うのが良い

AWS RDS MySQL Aurora

WEB+DB PRESS vol.94 特集1第5章P32 で、MySQL のクエリによる取得行数を取得するには、

mysql -u root -e "SHOW ENGINE INNODB STATUS\G" | grep "Number of rows"

を実行すると記載しましたが、Amazon Aurora の Reader(Read Replica) は SHOW ENGINE INNODB STATUS を実行しても何も結果を返さないためこの方法が使えません。
しかし、 SHOW GLOBAL STATUS WHERE variable_name = 'Innodb_rows_read' であれば Aurora の Writer, Reader に関係なく取得できます(もちろん RDS for MySQL でも OK です)。

mysql -u root -NBe "SHOW GLOBAL STATUS WHERE variable_name = 'Innodb_rows_read'" | awk '{print $2}'

ということで、 SHOW GLOBAL STATUS WHERE variable_name = 'Innodb_rows_read' を使うのがおすすめです！

【CentOS 6, Amazon Linux 対応】 unbound と ldns の RPM 作成方法

ldns unbound CentOS AmazonLinux RPM

epel repo から unbound が削除されました。

追記: CentOS6 の extras に unbound が入っているという情報をいただきました。@hfm さんありがとうございます！

無いなら作りましょう、ということで RPM 作成方法です。

検証環境

手順

CentOS 6 は unbound の tarball を取得して、同梱されている spec ファイルを少し書き換えて build すれば良いのですが、Amazon Linux には unbound が依存している ldns-devel がありません。
そのため、まず ldns の RPM を作ります。

yum-builddep と spectool を使うので、以下の package をインストールします。

yum install -y yum-utils rpmdevtools

ldns

まず、ldns の tarball に spec ファイルが同梱されているので取り出します。

curl -sO https://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.17.tar.gz
tar zxf ldns-1.6.17.tar.gz ldns-1.6.17/packaging/fedora/ldns.spec

ldns.spec の改行コードに CR がついているため rpmbuild に失敗するので削除します。

cat ldns-1.6.17/packaging/fedora/ldns.spec | tr -d \\r > ~/rpmbuild/SPECS/ldns.spec
## nkf でも OK
# nkf -Lu --overwrite ldns-1.6.17/packaging/fedora/ldns.spec
# mv ldns-1.6.17/packaging/fedora/ldns.spec ~/rpmbuild/SPECS/ldns.spec

そのまま spec ファイルを使うと Amazon Linux だとエラーがでます。
具体的には、

  • %{__python} を python に
    • /usr/bin/python が python2.7 になっていても %{__python} が python2.6 となるため、dist-package の path が 2.6 になるので no such file or directory でエラー
  • Source: の URL の typo でエラー

diff は以下のとおりです。

4,5c4,5
< %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
< %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")}
---
> %global python_sitelib %(python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")
> %global python_sitearch %(python -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")
10c10
< Version: 1.6.13
---
> Version: 1.6.17
14c14
< Source: http://www.nlnetlabs.nl/downloads/%{%name}/%{name}-%{version}.tar.gz
---
> Source: http://www.nlnetlabs.nl/downloads/%{name}/%{name}-%{version}.tar.gz

diff には含めていないですが、%changelog も更新しましょう。

次に、依存パッケージをインストールします。

yum-builddep -y ~/rpmbuild/SPECS/ldns.spec

tarball を ~/rpmbuild/SOURCES 以下に配置します。

spectool -R -g ~/rpmbuild/SPECS/ldns.spec
## mv でも OK
# mv ldns-1.6.17.tar.gz ~/rpmbuild/SOURCES/

準備が整ったので build します。

rpmbuild -ba ~/rpmbuild/SPECS/ldns.spec

これで ldns の RPM ができました。

unbound

まず、unbound の tarball に spec ファイルが同梱されているので取り出します。

curl -sO http://unbound.net/downloads/unbound-1.5.10.tar.gz
tar zxf unbound-1.5.10.tar.gz unbound-1.5.10/contrib/unbound.spec
mv unbound-1.5.10/contrib/unbound.spec ~/rpmbuild/SPECS/

unbound はバージョン以外は修正しなくても build できるので、 Version を書き換えます。 diff は以下のとおりです。

3c3
< Version: 1.4.18
---
> Version: 1.5.10

こちらも diff には含めていないですが、%changelog も更新しましょう。

次に、依存パッケージをインストールします。 自前の yum repo に ldns を追加していない場合は、build した RPM を予めインストールする必要があります。

rpm -ivh ~/rpmbuild/RPMS/x86_64/ldns-1.6.17-1.amzn1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/ldns-devel-1.6.17-1.amzn1.x86_64.rpm
yum-builddep -y ~/rpmbuild/SPECS/unbound.spec

tarball を ~/rpmbuild/SOURCES 以下に配置します。

spectool -R -g ~/rpmbuild/SPECS/unbound.spec
## mv でも OK
# mv unbound-1.5.10.tar.gz ~/rpmbuild/SOURCES/

Docker Container 上で RPM を build する場合に root で作業を行った際、spec ファイルの permission を変更しないと error: Bad owner/group /path/to/unbound.spec というエラーがでました。
その場合は以下のコマンドを実行します。

chown root: ~/rpmbuild/SPECS/unbound.spec

準備が整ったので build します。

rpmbuild -ba ~/rpmbuild/SPECS/unbound.spec

これで unbound の RPM ができました。

まとめ

ldns と unbound は spec ファイルが用意されているので少し書き換えるだけで RPM を作ることができました。
改行コードでエラーになるという問題は初めて遭遇したので勉強になりました。

追記(2017-03-31 17:05)

unbound.spec の useradd に -m がついてないため /var/unbound が作成されない問題があるようです。
以下のように修正すればよいです。

- useradd -r -g unbound -d /var/unbound -s /sbin/nologin \
+ useradd -r -g unbound -m -d /var/unbound -s /sbin/nologin \

あと、configure に --with-libevent をつけて build して libevent を使うようにしないと、

$ unbound -c /var/unbound/unbound.conf
Mar 31 08:17:33 unbound[9597:0] warning: too many file descriptors requested. The builtinmini-event cannot handle more than 1024. Config for less fds or compile with libevent
Mar 31 08:17:33 unbound[9597:0] warning: continuing with less udp ports: 477

のようなエラーがでる場合がありました(パラメータを調整すれば出ないようにすることもできました)。

mackerel-agent-plugin の diff の出力結果を加工してデータを per sec にする

mackerel-plugin-mysql を例にすると、

$ ./mackerel-plugin-mysql | grep Com_
mysql.cmd.Com_insert    0.000000        1475200487
mysql.cmd.Com_select    6.000000        1475200487
mysql.cmd.Com_update    0.000000        1475200487
mysql.cmd.Com_update_multi      0.000000        1475200487
mysql.cmd.Com_delete    0.000000        1475200487
mysql.cmd.Com_delete_multi      0.000000        1475200487
mysql.cmd.Com_replace   0.000000        1475200487
mysql.cmd.Com_set_option        0.000000        1475200487

は、1 分間に各 SQL をどれくらい実行したかという結果だと思いますが、
秒間どれくらい実行しているかというデータを見たいことがあると思います(少なくとも私は見たい)。

mackere-agent-plugin-helper の Metrics 構造体に Scale というフィールドがあり、データに指定の値を乗算する機能があります(キロバイトをバイトに変換したいときに 1024 をかけるみたいな感じ)。
これに 1 / 60 を渡せるようにすればよいかと思いましたが、 Metrics 構造体の Type が unit32 か uint64 の場合、 Metrics.Scale を uint32 または uint64 でキャストするので 0 になるためこの方法は使えませんでした。
プラグインを変更するにしても、Type を全部 float64 にしてしまうのは乱暴ですし、特定の値だけ 60 で除算する、というのをどうやって指定するのかという問題があります。

そこで、mackerel-agent-plugin の出力結果を加工してしまうという方法があります。
mackerel-plugin-mysql を例にすると、mysql.cmd.Com_* だけ 60 で除算したい場合、

$ ./mackerel-plugin-mysql | awk '{val=$2; if ($1 ~ /mysql\.cmd\.Com_/){ val = val / 60.0 } printf("%s\t%.6f\t%d\n", $1, val, $3) }'

のようにすれば OK です。
awk はちょっと... という場合は perl や ruby でも良いと思います。

※ go-mackerel-plugin-helper は、commit 04727eebfbb32b6ba54880d497fcaf94f18be810 時点のもので確認しています。

ISUCON6 予選2日目2位通過しました

ISUCON ISUCON6 予選

@hilotter さん、@Konboi と流れ弾として ISUCON6 予選2日目に参加して2位通過しました。
使用言語は Go で、私は足回りを整えて少しコードを書きました。

謝辞

運営の皆様ありがとうございました。
とても充実した時間を過ごすことができました。

やったこと

前日まで

  • メンバー各自で pixiv 社内 ISUCON 2016 を解く
  • 環境セットアップスクリプトを用意する
    • ユーザ作成、nginx、MySQL、Redis を簡単にいれられるようにしておく
  • デプロイスクリプトを用意する
    • 1台だけなので rsync & ssh で make all と systemctl restart する
  • alp の修正・PR merge
    • PR をくださった @vzvu3k6k さん、issue 報告してくださった @hilotter さんありがとうございました
  • nginx、MySQL、Redis の設定ファイルを作っておく

当日

起床成功

10:00 ~

  • Azure の VM 起動
  • アプリのコードを Bitbucket に push
  • isuter.go に patch をあてる
  • デプロイスクリプト微調整
  • nginx のログ集計
  • mysqldump をとる
  • pt-query-digest する
  • slowlog-sorter で遅いクエリを眺める

11:00 ~

  • go 以外の systemd の設定を消す
  • 他の二人がコードを読んでいる間にミドルウェアとアプリの再起動確認をする
    • reboot が 1, 2分くらいで終わるので楽だった
  • とにかく htmlify の正規表現が重いので初期データだけでも Redis にのせる準備を始める(@Konboi)
  • index をはる
  • url_for を消す

12:00 ~

  • ベンチ回す前に毎回ログを truncate するのが面倒になったのでデプロイ時にやるようにする
  • entry のクエリを修正(自己結合)
  • コードを読んだり、PRをレビューしたり

13:00 ~

  • SELECT COUNT を変数に持って実行しないようにする
  • isuda から直接 star テーブル読むようにする(@hilotter)

14:00 ~

  • login 時に session にユーザ名をいれて DB を参照しないようにする PR を作る(結局 merge していない)
  • アプリを Go で動かすようにしてから一度もスコアがでなくて絶望感漂う
    • perl のアプリでベンチを回したときに 2000 くらい出た以外はずっと 0
  • Go で書いたキャッシュ作成スクリプトが遅すぎて Perl で書き直す(@Konboi)
  • キャッシュを作っている間にキーワードの追加・削除時にキャッシュをどうしようか考え始める(@hilotter, @tkuchiki)

15:00 ~

  • キャッシュができたのでベンチを回す

f:id:tkuchiki:20160920150231p:plain

  • スコア 0 からいきなり 118245 になって全員のテンション爆上げ
    • ダッシュボードの Messages に色々出ているからだめかもという話しをしていたら idobata で PASS になっていれば大丈夫という発言を見て安心する
  • キャッシュの整合性を直すことは諦めてスコアの再現性を高めることに注力しようということになる
    • この判断を即決できたのが良かった

16:00 ~

  • ベンチを回すたびにキャッシュを作り直すスクリプトを作る(@Konboi)
  • 再起動確認を始める
    • Redis より isuda が先に起動しようとして起動に失敗することがあったので依存関係を設定
  • unix domain socket を使うようにする(問題が出たので元に戻した)
  • 以降、ひたすらベンチを回して再起動確認する、の繰り返し

感想

キャッシュの整合性は全く取れていないので Messages が一つでも出ていたら Fail または大幅に減点されていたら予選通過は無理でした(石とかまさかり投げないで...)。
我々の戦略で唯一良かったのは(というと二人に失礼ですが...)、アプリとしての正しさは無視して、すぐにスコアを安定させる方向に振り切ったことだと思っています。
スコアは一番良いときで 19万くらい低いときで 8万という感じだったので、多分大丈夫だろうという感じではありましたが、稀に Fail することがあったのと低いときのスコアが出たら予選通過できなさそうな雰囲気だったので、結果が出るまではだめかもと思っていました。
最終的に運良く予選通過できましたが力不足を感じたので、日々精進しなくてはならないなと改めて思いました。
本選は実力で結果を出したい...

あわせて読みたい

WEB+DB PRESS Vol.94 で特集「実践スケーラブルAWS」を執筆しました & 恵贈御礼

AWS WEB+DB PRESS

本日 8/24 発売の WEB+DB PRESS Vol.94 で、 特集1「［鍵は監視にあり！］実践スケーラブルAWS 規模に適した設計，負荷に応じた増減，障害への自動対応」
の第3章から5章を執筆しました。

gihyo.jp

謝辞

株式会社技術評論社 WEB+DB PRESS編集部様からご恵贈いただきました。ありがとうございます。
また、この度は執筆の機会をいただきましたこと重ねて御礼申し上げます。

もともと、fujiwara さん宛てに執筆依頼があったのですが、
無理を言って共著で書かせていただくことになりました。機会をいただきありがとうございました。

f:id:tkuchiki:20160819201510j:plain

特集「実践スケーラブル AWS」について

この特集では、AWS で1〜100台規模のサーバを運用する際、どのようなことを考えて設計するとスケールしやすくなるのか解説しています。
今まで WEB+DB PRESS またはその他の雑誌で、数多くの AWS の特集が組まれてきたと思いますが、
本特集ではタイトルにもあるように「監視」に重点を置いた内容となっております。
第2章では運用における監視についてやどのような監視が必要かを　Zabbix と Mackerel を例に紹介しています。第3章ではWeb・アプリケーションサーバ、第4章ではキャッシュサーバ(memcached と Redis)、第5章ではデータベースサーバ(MySQL) の監視について記しております。第6章では、オートスケールの監視について触れています。特に3〜5章では、各章2ページほど監視について紙面を割いています。
全体を通して、まだAWSでの監視やオートスケールに取り組んでいない方もすでにがっつり運用されている方にも参考になる内容になっているのではないかと思います(そうであれば幸いです)。

特集は32ページありますので、読み応えがあると思います。
是非、お手にとっていただけますと幸いです！