コマンドの実行結果から、他のコマンドを実行したいというのはUnix / Linux系のOSでは良くあることだと思います。
そんなときパイプを使ったり、xargsを使ったりして処理すると思うのですが、例えばディレクトリ内の３０日以上経過したファイルを一括で消したいという時には
find . -mtime +30 -print | xargs rm
とか
find . -mtime +30 -exec rm {}¥;
とかして、実施すると思います。でも、例えば対象ファイルをgzip圧縮したいという場合だと、上記の方法をそのまま
find . -mtime +30 -print | xargs gzip
とか
find . -mtime +30 -exec gzip {}¥;
のように実行してしまうと、１ファイル毎に圧縮するので圧縮するためのプロセスが１つしか同時に起動していないので、最近のマルチコアのCPUを使っても処理速度が遅かったりします。こういう場合にxargsのオプションを使うと同時に複数のgzipを起動出来る事が判りました。xargsのオプションに-Pというのがあって、コマンドを同時に複数発行してくれる。manを読むとParallel mode: run at most maxprocs invocations of utility at once.とか書いてあって、目から鱗です。
例えば、上の例だと
find . -mtime +30 | xargs -P 4 gzip
と実行すると、あら不思議。同時にgzipが4つ起動するじゃありませんか。その時gzip毎に別のプロセスが起動するので当然のことながら、CPUの別のコアを使って処理されたりします。
ちょっとだけ速く処理できるという事で、便利、便利。
PROXYサーバをLinuxのLVS（ipvsadm）を使って冗長構成にする事を考えました。
LVSは既に使っている（RedHat Enterprise LinuxでWebサーバロードバランス）のですが、ここではWebサーバのバランシングではなく、Proxyサーバのバランシングを行います。
また、前回の検証時はRedHat Enterprise Linux ES3を使って検証を行っていましたが、今回はUbuntu Server 12.04LTSを使います。ipvsadmがディストリビューションに含まれているため、それにあわせてファイルの配置が変更になります。検証機も実機ではなくESXi上に立てることにします。
今回も目的はProxyサーバの耐障害性の向上で、負荷分散を目的とはしていませんが、構築の順序としては負荷分散機能（ipvsadm）→耐障害機能（keepalived）となります。
※Proxyサーバの仮想IPアドレスは192.168.100.10にする
論理的にはロードバランサーがクライアントからの要求をすべて受けて、２台のProxyサーバに振り分ける構成になるため、図のようにロードバランサーの配下にProxyサーバ２台がぶら下がる構成になります。
物理的には同一セグメントでフラットに接続されている構成になります。
ロードバランサーの構成をNATにしてしまうと、ProxyサーバのアクセスログにクライアントのIPアドレスではなく、ロードバランサーのIPアドレスが記録されてしまう弊害がおきるため、構成はDSRにします。この構成の大きなメリットが２つあり、１つ目がソースIPアドレス（クライアントのIPアドレス）がそのままサーバに伝わることと、戻りパケットの処理にロードバランサーが介在しないことで、ロードバランサー自身の負荷が少なくなる事です。 デメリットはリアルサーバ側に若干細工が必要になることですが、今回はPROXYサーバも自前のため、デメリットになりません。
Proxyサーバの待ち受けポートは8080を使用しています。
ESXi上のゲストOSで動作させているDovecotがお亡くなりになる症状が出ました。
エラーログを見ると
Jul 21 18:39:10 mail dovecot: imap: Fatal: Time just moved backwards by 18 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki2.dovecot.org/TimeMovedBackwards
Jul 21 18:39:11 mail dovecot: imap: Fatal: Time just moved backwards by 17 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki2.dovecot.org/TimeMovedBackwards
Jul 21 18:39:13 mail dovecot: imap: Fatal: Time just moved backwards by 17 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki2.dovecot.org/TimeMovedBackwards
というエラーを吐いていて意訳すると
時間が18秒も戻ってるよ。なんか、すげーヤバイ。オレ、とりあえず落ちるわ。後ヨロ（http://wiki2.dovecot.org/TimeMovedBackwards 見といてね）
とかそんな感じ。
あと、ntpdは時間のズレが激しすぎるとSTEP動作になっていきなり時間を戻してしまうから、-xオプションを付けて起動するか、ntp.confに"tinker step 0"と書いておくこと。
みたいに書かれていたので、その通り/etc/default/ntpに
NTPD_OPTS='-g'
↓
NTPD_OPTS='-g -x'
起動オプションとして -x を追加した。
ただ気になるのが、ntpdで時刻同期をしていたのにOSの時刻が著しくずれていたという点。
普通であれば、ntpdは時間のズレを少しずつ補正する（Slew動作）のだが、そのズレが著しい場合には一気に時間を補正する（Step動作）。ここで問題になっているのはOSの時間が著しくずれていたからStep動作で時間が一気に巻き戻った→Dovecotが時間の巻き戻りを検出して自殺した、という部分なので、ntpdの動作オプションで -x を付けて起動する事でStep動作への切り替わりを発生しにくく抑止したことは対処療法でしかなく、根本的にはOSの時刻が著しくずれていた事が問題になる。
なぜ？
メールサーバはここ何年ずっとDovecotで運用してきている、ntpdの設定もほぼ同じ。その間プラットフォームは色々と移っているが、その間問題無く動いていた。
思い当たる節は・・・仮想化？(ESXi）
そういえば・・・と思い出したのが、VMware Server上でLinux Kernel 2.6を動作させると時間がずれるという話。
仮想化環境でLinuxを動かすときは何かTipsがあったんじゃないかと思い出して調べてみたところ、アタリっぽい。
VMware-toolsの設定でホストとの時間調整を行わない設定にして、時刻同期はntpdのみとした。
$ sudo vmware-toolbox-cmd timesync status
$ sudo vmware-toolbox-cmd timesync disable
全てのゲストOSにその設定を行って、様子を見ることにした。
Google先生に「Linux リゾルバキャッシュ」とか聞くと、無い！と答えが返ってきますが、
残念ながらnscdとか言うのがあります。
普通にservice nscd stopとかすれば止まりますが。。。
Ubuntu 12.04 LTSの日本語Remixが5月3日(木)にリリースされてました。ダウンロードページにリンク張っときます
５月のGW前後でリリースされたので、タイミング的には例年通りです。
内容は色々と変わっているのですが、今回気になっているのがサポート期間です。
10.04 LTSの時まではデスクトップ版が3年、サーバ版が5年だったのですが、12.04 LTSではどちらも5年間のサポートになっています。※リリース時期とサポート期間を参照（2017年の４月までと書かれている）
オリジナルがリリースされたときはあえてパスして、日本語Remix待ちをしていたのですが、そちらがリリースされたのでX100eにはアップデートマネージャからアップデートしました。（元々日本語Remixからインストールして、都度アップデートしてきたものです）
正直UbuntuもUnity化されてから非常に重たくなってきたので、Unity→Ubuntu Classic（素のGNOME環境に近いもの）に切り替えて使って居ます。それでもX100eでは何をやっても遅いのは仕方無いのでしょうけど。それでもプリインストールされているWindows7Home環境ではブラウザすらまともに使えないので、まだマシという言い方も出来るのですが。