マイノリティでいこう Linuxその他雑多なこと

サーバの管理ボードをリセットする ipmitool mc reset cold

最近のサーバだと大体付いているipmi

統一規格のため、メーカが違っても同じように使えるし、linuxでも問題ないのでかなり重宝している。

リモートから電源を上げられたり、OS不要でボードの状態を確認出来たりと、今までお手上げ状態だった状況からもなんとか復旧出来たりする。

ただ、たまにipmiの管理ボード自体がおかしくなってるときがある。(特に管理WEBへのhttpsでコケる気がする)

そんなときは、管理ボード自体を再起動できる。しかもOS側は動作したままで！

# ipmitool mc reset cold

1	# ipmitool mc reset cold

上記実施後、5分くらいで管理ボードの再起動が終わります。IBM、NEC、FUJITSU筐体で試してはいるが、どのメーカもOS側には何ら問題はなかったので他メーカでも問題無いと思う。

また、上記コマンドですが、debian系ならそのままの名前ipmitoolでインストール出来ると思う。

centosでは、OpenIPMI-toolsでいけると思う。追加のリポジトリ(remiとかrpmforgeとか)が必要かも。

シンクのゴミ取り(ゴミカゴ？)

マンションの流し(シンク?)の排水口に備え付けてある
ゴミ取り(ゴミカゴ?)が、非常に穴が小さく
ゴミのない綺麗な状態でも、非常に流れが悪く
イライラする日々が続いていた。

こんなモンどこに売ってるんだろう？
というかそもそも名称がわからず検索してみると
さすがamazon売ってるんですね。

【抗菌】Belca 排水口ゴミ受け流し用ゴミカゴ 80タイプ直径8cm用直径8×高さ16.4cm ホワイト日本製 SP-106W

amazon

サイズが心配ですが、おそらく1Kのマンションだったら、大体直径8cmなんじゃないかな。

特に問題なくハマった。

しかも送料無料。

こりゃ実店舗じゃ扱えないような、ニッチな製品だし
amazon恐るべし。

django1.5にアップデート時のurl

自分の開発環境のubuntuを13.04にアップデートしたら、
pythonのvirtualenv環境が変になった。

virtualenv環境を新しくして、pipでdjangoをインストールしたところ
1.4から1.5に上がってしまい若干の修正が必要だった。

'url' requires a non-empty first argument. The syntax changed in Django 1.5, see the docs.

1

'url' requires a non-empty first argument. The syntax changed in Django 1.5, see the docs.

こんなエラーが表示される。

調べたところ、template内の、{% url foo.bar %}が問題らしい。

ここを

{% url "foo.bar" %}

1	{% url "foo.bar" %}

とクオートで囲んであげれば、現象回避できる。

自分の場合は、さほど数が多く無いので手動で行ったが、
多い場合は、スクリプトで対処が必要かと。

http://stackoverflow.com/questions/13590699/migrate-url-tags-to-django-1-5

テンプレートの、拡張子がhtmlならこんな感じでしょうか。(未検証)

(一応sed時に*.BKでバックアップも残して)

$ find . -type f -a -name "*.html" -print0 | xargs -0 sed -i.BK -r -e "s#\{% url ([a-zA-Z0-9_.-]+)#\{% url '\1'#g"

1	$ find . -type f -a -name "*.html" -print0 \| xargs -0 sed -i.BK -r -e "s#\{% url ([a-zA-Z0-9_.-]+)#\{% url '\1'#g"

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に期待しすぎなのかもしれません。