nb | マイノリティでいこう

vimのNERDTreeで特定のファイルを表示しない方法

なんてことはない、.vimrcにNERDTreeIgnoreを指定するだけ。

pycファイルを表示しない場合は、

let NERDTreeIgnore = ['\.pyc']

1	let NERDTreeIgnore = ['\.pyc']

複数指定したい場合は、カンマで区切る

let NERDTreeIgnore = ['\.pyc$', '\.png$']

1	let NERDTreeIgnore = ['\.pyc$', '\.png$']

山中慎介選手のトランクスに秘められた名前

続編あり

2013年4月8日(月) 山中慎介 vs マルコム・ツニャカオを国技館で観戦した。試合内容は、色々な記事で取り上げられている通りすばらしく大満足だった。また他の世界戦2試合も十分の内容で、ボクシングの醍醐味を堪能した一日だった。

国技館という会場も、2階席からでも角度があって非常に見やすかった。あの~国際フォーラムやめませんか。。。

山中選手のトランクスだが、以前から一人の氏名が刺繍されている。

辻昌建

リング上での悲しい事故で亡くなられた方の名前で、山中選手と同じ帝拳ジムに所属していた。

おそらく一緒に切磋琢磨した仲間で、特別な思いを込めて刺繍しているのだろう。

こういった美談だと、テレビなんかが食い付いて紹介しそうなものだが、私が見逃しただけかもしれないが、取り上げられたことが無いように思う。

多くを語らず、行動で示す、いぶし銀なところが、ボクシングの魅力だけでなく人間的な魅力も感じさせてくれる。

その山中選手のトランクスだが、今回の試合でまた一人の氏名が刺繍されている。

http://ameblo.jp/stanbox7/entry-11507983519.html

こちらの記事をよく見ると、トランクス右後ろに

上西孝幸

と読める。

ネットで調べてもまったく情報がないのだが、名前だけで検索してみると滋賀県障害者スポーツ協会のページがヒットする。

滋賀県といえば、山中選手の出身地で、また何か秘められた思いがあるのだろうと想像を膨らましてしまう。

今後も、ボクサー山中選手、人間山中慎介を応援し続けたい。

etckeeperでLinuxサーバのコンフィグバージョン管理

長年悩んでいたが、linuxサーバのコンフィグ(/etc以下)のバージョン管理について良さげなのを見つけた。

その名もetckeeper

gitやbzrなどのバージョン管理と連携してくれる見たいで、おそらく要望通り。

動作としては、/etc/内にリポジトリを作り、一日一回更新してくれる模様。yum実行後にも更新してくれるらしい。

CentOS6でのインストールはepelが追加されていればyumで一発

# yum install etckeeper

1	# yum install etckeeper

インストール後、初期化して上げます。

# etckeeper init
Initialized empty Git repository in /etc/.git/

1 2	# etckeeper init Initialized empty Git repository in /etc/.git/

とりあえず最初のcommitをします。

# etckeeper commit "First commit"
[master (root-commit) 482c04a] First commit
1549 files changed, 98856 insertions(+), 0 deletions(-)
create mode 100755 .etckeeper
create mode 100644 .gitignore
--snip--

# etckeeper commit "First commit"

[master (root-commit) 482c04a] First commit

1549 files changed, 98856 insertions(+), 0 deletions(-)

create mode 100755 .etckeeper

create mode 100644 .gitignore

--snip--

あとは、定期的に自動でcommitされるはずです。
基本gitなんで、ステータスとかログは、gitコマンドで見れます。

まだインストールしただけなんで、感想とかは無いです。

scpのETAって何？

scpしていると右下に、ETAと時間らしきものが表示される。

# scp -l 30000 foo@example.com:~/hoge.tgz ./
foo@example.com's password:

hoge.tgz       5% 1094MB   3.6MB/s 1:32:30 ETA

# scp -l 30000 foo@example.com:~/hoge.tgz ./

foo@example.com's password:

hoge.tgz 5% 1094MB 3.6MB/s 1:32:30 ETA

どうやら(Estimated Time of Arrival)の略らしい。

翻訳サイトで確認すると、(到着予定時刻)らしい。

まー予想通り。

fallocateで素早く仮想化ディスクを用意する

今まで、仮想環境のディスクファイルなんかで使う大きめのファイルといえばddでzero fillをしていたが、

実際にディスクにzeroを書き込むので遅くて困っていた。

1Gファイルを作るとき

$ dd if=/dev/zero of=1G.bin bs=1M count=1024

1	$ dd if=/dev/zero of=1G.bin bs=1M count=1024

最近だとfallocateの方が良いっぽい。

同じく1Gファイルを作るとき

$ fallocate -l 1G 1G.dat

1	$ fallocate -l 1G 1G.dat

sparse fileじゃなくてちゃんと確保してくれている模様。

ext4からの機能らしい。

シェルスクリプトを書いていると、エラー処理を書くのが面倒で、とりあえずbashをeオプションで起動しておけばいいや程度に思っていたりします。シェルスクリプト中のどこかでエラーが出ればスクリプト自体を終了してくれるので何かと便利なんですが、途中無視できる程度のエラー処理で止まって困ることもあるので、そこを何とか無視する方法を調べました。まーmanに書いてあったんでちょっと読めば気付くんでしょうが自分は結構時間かかりました。

-e 単純なコマンド (前述のシェルの文法セクションを参照) が 0 でないステータスで終了した場合、即座に終了します。ただし失敗したコマンドが until または while ループの一部である、 if 文の一部である、 && または ││ リストの一部である、コマンドの返り値が ! で反転されている、のいずれかの場合にはシェルは終了しません。

上の条件に当てはめてしまえばいいだけです。

サンプルとして、以下のようなスクリプト。

#!/bin/bash -e

echo "最初のecho"
/bin/false || echo エラーでも続行

echo "多分ここで終わる"
/bin/false

echo "これは出ないはず"

#!/bin/bash -e

echo "最初のecho"

/bin/false || echo エラーでも続行

echo "多分ここで終わる"

/bin/false

echo "これは出ないはず"

最初のfalseでは、止まらず次のfalseで止まって、最後のechoは処理されないはずです。

メモリをメッチャ使ってみる

前回cpuに負荷をかけてload averageをメッチャ上げてみたが、今度は、メモリをひたすら消費するとどうなるか見てみます。

今回もwatchdogタイマーの動作具合を見るのが目的です。

まず、以下のようなコードを書いて

#include <stdio.h>
#include <stdlib.h>

int main(  )
{
int i = 0;
while (1){
char *str;

/* 文字列のためのメモリを確保 */
str = (char *)malloc(1024);
if(str == NULL) {
printf("メモリが確保できません\n");
printf("10秒待ちます\n");
sleep(10);
}
if ( (i % 10240) == 0 ){
printf("%d MBytes\n", (i / 1024 ));
}
i++;

}
return 0;
}

#include <stdio.h>

#include <stdlib.h>

int main( )

{

int i = 0;

while (1){

char *str;

/* 文字列のためのメモリを確保 */

str = (char *)malloc(1024);

if(str == NULL) {

printf("メモリが確保できません\n");

printf("10秒待ちます\n");

sleep(10);

}

if ( (i % 10240) == 0 ){

printf("%d MBytes\n", (i / 1024 ));

}

i++;

}

return 0;

}

コンパイルして、

./gcc -o mem_full mem_full.c

1	./gcc -o mem_full mem_full.c

実行します。

$ ./mem_full

0 MBytes
10 MBytes
20 MBytes
-- snip --

2600 MBytes
2610 MBytes
強制終了

$ ./mem_full

0 MBytes

10 MBytes

20 MBytes

-- snip --

2600 MBytes

2610 MBytes

強制終了

メモリをジワリジワリと消費して行って、そのうち強制終了されると思います。

その間、経過を見るため他のコンソールでtopします。

$ top
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
7219 gpowers   20   0  867m 866m  344 R 73.0 45.7   1:32.67 mem_full

$ top

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7219 gpowers 20 0 867m 866m 344 R 73.0 45.7 1:32.67 mem_full

RESの値が搭載メモリ近くになると、強制終了すると思います。このRESの値が実際に確保する値です。malloc時に

もっと多めに取れば、早く確保出来ると思ったのですが、あまり値が大きいと仮想メモリ(VIRT)ばかり増えて、

実メモリ(RES)が少ししか増えなかったので、小さめにしていっぱい回します。

RESが搭載メモリ近くになると、コンソールの反応とかも悪くなりますが、しばらくすると対象プロセス(mem_full)が

強制終了されます。この強制終了は、有名なoom-killerさんが行なってくれます。

syslogを見ればそんなメッセージがあると思います。

ただ、必ず予想していたプロセス(mem_full)とは限らず、他の正常プロセスも落とされる可能性があります。

ここまでやってメモリを食い尽くすプロセスがいても、きっとoom-killerさんが良きに計らってくれるので

watchdogタイマーで落ちることは無さそうです。

せっかくなので、今度は、メモリ食い尽くしプログラムを同時多発的に実行してみます。

$ for i in `seq 1 100`; do ./mem_full & done

1	$ for i in `seq 1 100`; do ./mem_full & done

とりあえず100個実行します。topで見るとわんさかプロセスがいます。

コンソールのレスポンスも激遅になり、topの表示も更新されなくなるが

地味にoom-killerさんも動いており、watchdogのリセットが実行される形跡はありません。

watchdogデバイスに定期的に書き込んでいるのは、CentOSにあったその名もwatchdogな

パッケージでインストールしたデーモンなんですが、こいつが何とか頑張っているようです。

この状況だとコマンドも打てないので、強制的に電源を落とすしかありませんでした。

watchdogの意味なし。

一応CentOSのwatchdogでは、load averageにしきい値を設定出来そうなので

それで対処するのもありかと思います(未検証)。

ただしきい値の設定は頭の痛いところです。因みにこのテスト実施時は160くらいいってました。

また、デーモンタイプのwatchdogでは性能が良すぎるのかとも思います。都度コマンドを実行して

デバイスに書き込むタイプの簡易的なものなら、おそらくコマンドの実行が出来ずwatchdogからリセットがかかる可能性が高い気がします。

うーん。watchdogに期待しすぎなのかもしれません。

load averageをメッチャ上げてみる

watchdogタイマーとか仕込んでみて、ふとload averageメッチャ上がってる時に、書き込めなくて落とされたりしないのだろうかと思って
load averageをこれでもかって上げてみた

for i in `seq 1 100`; do dd if=/dev/urandom of=/dev/null & done

1	for i in `seq 1 100`; do dd if=/dev/urandom of=/dev/null & done

/dev/urandomをひたすらddで取ってくるだけ。

# w
14:27:56 up 26 min, 2 users, load average: 109.21, 95.65, 53.50

1 2	# w 14:27:56 up 26 min, 2 users, load average: 109.21, 95.65, 53.50

load average 100超えてるけど、とりあえず落とされることはないですね。
本番環境だと、何が原因で上がってるのかアタフタしますが、
上げる気になれば簡単に上げられますね。
ただこれだと、CPUには負荷かかってるけど、メモリやI/Oは全然使ってないので
その点も検証する必要がありそう。

シェルでMACアドレスをランダムに生成

ちょっと悩んだので自分用にメモ。
表題の通り、シェルでMACアドレスをランダムに生成する方法。仮想化なんかで、ゲストを自動作成するスクリプトを書いていると、固有のMACアドレスが必要だったりするのでそのメモ。

printf "%X:%X:%X:%X:%X:%X\n" $(($RANDOM % 255 )) $(($RANDOM % 255 )) $(($RANDOM % 255 )) $(($RANDOM % 255 )) $(($RANDOM % 255 )) $(($RANDOM % 255 ))

1	printf "%X:%X:%X:%X:%X:%X\n" $(($RANDOM % 255 )) $(($RANDOM % 255 )) $(($RANDOM % 255 )) $(($RANDOM % 255 )) $(($RANDOM % 255 )) $(($RANDOM % 255 ))

エレガントでは無いけど、これだけ。
%Xを%xと小文字にすれば、小文字のアドレスが生成される。OUIを指定したかったら、最初の3オクテットを固定にするだけ。

ubuntu 12.10 で SPICE

仮想化と言えば、最近は一貫してkvm(libvirt経由の更にvirt-managerでの)だが、

サーバ用途では全く問題ないが、クライアントとなるとグラフィックがどうしても貧弱で

ちょっとだけ困っていた。最近のvirt-managerの設定をみると、VNCと同じ箇所で、

spiceなるものが選べるようになっていたのだが、ちょっと調べてみたらなんか良さそうなので

とりあえず試してみることにした。spiceに詳細については、ネットで調べるとあまり多くないですが

情報が得られます。

まず、必要パッケージのインストール

# sudo sudo apt-get install qemu-kvm-spice spice-client spice-client-gtk python-spice-client-gtk

1	# sudo sudo apt-get install qemu-kvm-spice spice-client spice-client-gtk python-spice-client-gtk

virt-manager(仮想マシーンマネージャー)で、ディスプレイを、spiceに
ビデオカードを、qxlに変更します。

なぜか起動時に、
unsupported configuration: spicevmc not supported in this QEMU binary
とかってエラーがでます。

インストールした、qemu-kvm-spiceコマンドを使ってないのが問題なようなので
virshコマンドで手動で変更します。

$ virsh edit [編集したいVM名]

1	$ virsh edit [編集したいVM名]

<emulator>/usr/bin/kvm</emulator>

1	<emulator>/usr/bin/kvm</emulator>

を、

<emulator>/usr/bin/kvm-spice</emulator>

1	<emulator>/usr/bin/kvm-spice</emulator>

に変更する。

とりあえず、これで仮想マシンは起動します。

起動したゲスト側で、ドライバが必要な場合は、別途インストールが必要です。
ゲストがWindowsの場合は、
http://spice-space.org/download.html
から、「Guest」の「Windows binaries」をゲストのWindowsにインストールします。

なんかインストール時に聞かれますが、テキトーに答えれば進めました。

最近のウィンドウズだと、ドライバに署名が無いとインストール出来ない場合があるのですが、

なんとかすれば回避できると思います(雑)

spiceにしてみてですが、なんとなく快適になったような気がします。

品質はあまり良くないですが音もでます。

投稿者: nb