bluegold » opensolaris

OpenSolaris 134b で php-cgi が動作しない

bg — Tue, 23 Nov 2010 14:58:03 +0000

Oracle Solaris 11 Expressがようやく公開されました。このブログを動かしている OpenSolaris 2009.06 の次のバージョンは、当初 OpenSolaris 2010.02 になるはずだったので、9ヶ月遅れてのバージョンアップとなりました。

Sun が Oracle に買われて以降、Solaris がどうなるのかハッキリしない状態が続いていたので、新しいバージョンがリリースされた事は良かったと思います。OpenSolais の体制のままで新バージョンがリリースされていれば最高だったんですけどね。

リリースはされましたが、Oracle Solaris 11 Express は snv_151 で、OpenSolaris 2009.06 の snv_111b からは大きく変わっているらしく、一回でアップグレードはできません。一度 snv_134b（キャンセルされていた OpenSolaris 2010.06 になるはずだったバージョンですね）に上げた後で、パッケージリポジトリ（パブリッシャ？）を変更して再度アップグレードを行う必要があるようです。

最終的に Oracle Solaris 11 Express（毎回書くのは長いな、略称は何だろ？）を使うか、OpenIndiana を使うようになるかは分かりませんが、どちらにしろ 134b にアップデートしておく必要はあるみたいです。

134b へのアップデート方法

アップデートはpkg image-updateコマンドで行いますが、先に SUNWipkg パッケージを更新しておく必要があるみたいです。

pfexec pkg install SUNWipkg
pfexec pkg image-update -v --be-name snv_134b

いろいろとパッケージをインストールして遊んでいたので、2時間くらいかかりました。

本番環境をアップグレードする前に VirtualBox に OpenSolaris 2009.06 をインストールして、アップデートの実験は何度もしていたので、この手順自体は問題なく終わりました。svcsコマンドでサービスの起動状況を確認して、maintenance になっているものも無かったので、アップグレードは無事終わったかと思っていましたが、ブログを表示させようとするとこんな感じになっていました。

お使いのサーバーの PHP では WordPress に必要な MySQL 拡張を利用できないようです。

問題の調査

php-cgi コマンドが正常に動いていないのか、と思い直接実行してみると

# /usr/php/bin/php-cgi -v
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/apc.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/apc.so: シンボル compiler_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/bz2.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/bz2.so: シンボル core_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/curl.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/curl.so: シンボル core_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: ftp: Unable to initialize module
Module compiled with module API=20060613, debug=0, thread-safety=1
PHP    compiled with module API=20060613, debug=0, thread-safety=0
These options need to match
 in Unknown on line 0
（略）
PHP 5.2.12 (cgi-fcgi) (built: Apr  5 2010 20:00:17)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

マルチスレッドでない PHP のプロセスから、マルチスレッドを有効にしたモジュールを読み込もうとして失敗しているようです。php コマンドは正常に動作していましたが、nginx は CGI を使えない。そもそも zts-modules なんてディレクトリは php.ini で指定していないのに、どこから出てきたのかがわかりません。

しばらく悩みましたが、phpinfo() の出力を見て、ようやく気がつきました。

Loaded Configuration File	/etc/php/5.2/nsapi/php.ini

これまでは/etc/php/5.2/php.ini を読んでいたのが、バージョンアップ時に変わってしまっていたようです。NSAPI 用の php.ini ならスレッドセーフのモジュールを読むのは自然です。（NSAPI が現役なのかは知りませんが。自分で最後に NSAPI モジュールを書いたのは13年くらい前か。）

原因は分かれば修正は簡単で、/etc/php/5.2/nsapi/php.ini を以下のように修正して問題解決。

543c547
< extension_dir=/usr/php/5.2/zts-modules
---
> extension_dir = "/usr/php/5.2/modules:/var/php/5.2/modules"

nginx を SMF で管理する

bg — Mon, 02 Aug 2010 16:36:59 +0000

もう1年以上前に書いていた下書きをようやく公開。

前回（と言っても1年半前か）までで nginx と PHP の fast-cgi のビルドと設定が終わったので、OS の起動時に自動的に起動するようにサービスとして登録を行います。

OpenSolaris ではサービスの管理に SMF という仕組みを使用しています。SMF はサービスの依存関係を記述できたり、サービスの起動を監視して自動的に再起動してくれたりと、Linux などで使われている /etc/init.d の rc スクリプトに比べるとメリットがありますが、コマンドが独自だったり、自分で SMF にサービスを登録するには manifest と呼ばれる XML ファイルを書く必要があるので、慣れるまではハードルがあります。（この辺は Mac OS X の launchd と似ている。）

以下が、私が nginx を管理するために作成した nginx.xml です。

このファイルを以下のように SMF に登録します。

# svccfg -v import nginx.xml

同様に PHP の FastCGI のプロセスも SMF に登録します。

この xml も同じように svccfg コマンドで登録します。

起動用の shell スクリプトはこちらのサイトのものを、ほぼそのまま使っています。

#!/bin/bash

LC_ALL=ja_JP.UTF-8

#FastCGI Webserver path
FCGI_WEB_SERVER_ADDRS="127.0.0.1"

## ABSOLUTE path to the PHP binary
PHPFCGI="/usr/php/bin/php-cgi"

## tcp-port to bind on
FCGIPORT="9000"

## IP to bind on
FCGIADDR="127.0.0.1"

## number of PHP children to spawn
PHP_FCGI_CHILDREN=5

## number of request before php-process will be restarted
PHP_FCGI_MAX_REQUESTS=1000

# allowed environment variables sperated by spaces
ALLOWED_ENV="PATH"

## if this script is run as root switch to the following user
USERID=webservd

################## no config below this line

ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_CHILDREN"
ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS"
ALLOWED_ENV="$ALLOWED_ENV FCGI_WEB_SERVER_ADDRS"

if test x$UID = x0; then
  EX="/bin/su -m -c \"$PHPFCGI -q -b $FCGIADDR:$FCGIPORT\" $USERID"
else
  EX="$PHPFCGI -b $FCGIADDR:$FCGIPORT"
fi

echo $EX

# copy the allowed environment variables
E=

for i in $ALLOWED_ENV; do
  E="$E $i=${!i}"
done

# clean environment and set up a new one
nohup env - $E sh -c "$EX" &

サービスが SMF に登録できれば、svcadm コマンドで起動停止を切り替える事ができます。

起動

# svcadm enable nginx
# svcadm enable php-fastcgi

停止

# svcadm disable nginx
# svcadm disable php-fastcgi

Redmine を監視して再起動する

bg — Tue, 20 Apr 2010 16:35:50 +0000

正確には Redmine が原因なのかどうかは判明していませんが、OpenSolaris 上に構築した Redmine が起動後何時間かすると500 Internal Errorを返すようになってしまいました。

Redmine は以下のような環境で動かしています。

Redmine 0.9.3
OpenSolaris 2009.06
Ruby 1.8.7-p249
Rails 2.3.5
Unicorn 0.97.0
nginx 0.7.65

Ruby は /opt/sunstudio12.1/bin/cc(Sun Studio Express 12)でビルドしています。

OpenSolaris に付属の /usr/bin/ruby を使っていた時には問題なく動作していたんですが、Redmine 0.9.3 にバージョナップした所、致命的な問題が発生したため、Ruby を自分でビルドするように変更していました。

落ちているの気がついたら手動で再起動をしていたのですが、さすがにメンドウになってきたのでスクリプトを書きました。

#!/bin/sh

while `/bin/true`
do
    http_code=`curl --insecure -w "%{http_code}" -s -o /dev/null https://redmine/login`
    ts=`date +"%Y/%m/%d %H:%M:%S"`

    if [ $http_code -eq 200 ]; then
        echo $ts OK
        sleep 300
        continue
    fi

    cd /var/www/redmine
    pid=`cat tmp/pids/unicorn.pid`

    kill -USR2 $pid
    sleep 5
    kill $pid

    echo $ts unicorn $pid reloaded.
done

exit 0

手順としては、5分おきに curl で HTTP のステータスコードのみを受け取り、200 OKが帰ってこない場合は再起動、という流れです。

Unicorn は SIGUSR2 を送ると自分自身を fork() してから終了するはずなのですが、終了せずに残るので子プロセスの起動を待ってから SIGTERM を送っています。

とりあえずは、これで気にはならなくなりましたが。。。

そのうち、God あたりに切り替えよう。

Mercurial: nginx で hgwebdir.fcgi のセットアップ

bg — Sun, 07 Feb 2010 15:04:09 +0000

Mercurial 付属の hgwebdir.fcgi を nginx で動かすメモ

CVS（やSubversion）をバージョン管理システムに使っていた頃はリポジトリの情報を見るのにViewVCを使っていましたが、ViewVCはMercurialをサポートしていません。Mercurial にはウェブ用の管理画面(hgweb/hgwebdir)が付属しているので、別のツールを使うニーズが少ないんでしょうね。

Mercurial のリポジトリ毎に対応する Redmine のプロジェクトが存在するので、そちらを見ればおおよその事は分かるのですが、Redmineのリポジトリブラウザはブランチを意識して作られていないので不便といえば不便です。

hgwebの事は Mercurial への移行を検討していたときにも調べていたんですが、Django, flup, setuptools, ez_setup.py, easy_install, .. とPythonに不慣れな人間にはなじみのない単語が続々と出てきたので、ちょっと敬遠していましたが、ちょっと時間が取れたのでチャレンジしてみました。

hgwebdir のセットアップをする前に必要なソフトウェアのインストールを行います。環境は OpenSolaris 2009.06 で、可能な限り pkg を使ってインストールしていきます。インストールしたのは以下のパッケージです。

SUNWPython26
SUNWPython26-extra
SUNWpython26-setuptools

OpenSolaris 2009.06 のパッケージ管理システムにも Mercurial はありますが、バージョンが 1.1.2 と古く、クライアントの環境と合わないので、最新バージョンを easy_install からインストールします。

$ pfexec easy_install Mercurial
$ hg --version
Mercurial Distributed SCM (version 1.4.2)

Copyright (C) 2005-2009 Matt Mackall  and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

次に flup が必要だそうなのでインストールします。

$ pfexec easy_install flup

hgwebdir を FastCGI で動作させるのにはいろいろな方法があるらしいのですが、Python特有のやり方はよく分からないので、lighttpd の spawn-fcgiを使いました。インストールは以下の通り簡単です。

$ wget http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz
$ gzip -dc spawn-fcgi-1.6.3.tar.gz | tar xvf -
$ cd pawn-fcgi-1.6.3
$ ./configure
$ make
$ pfexec make install

ここまででようやく下準備がおわりました。
hgwebdir.fcgi は /usr/demo/mercurial/hgwebdir.fcgi をコピーして使っています。
UTF-8 で表示するために、HGENCODING の設定を行う部分のコメントをはずしています。

os.environ["HGENCODING"] = "UTF-8"

hgweb.config は単純です。

[paths]
/ = /path/to/repos/*

これを以下のようなスクリプトで起動しています。

#!/bin/sh

LANG=ja_JP.UTF-8
export LANG

FCGI=/opt/local/bin/spawn-fcgi
exec $FCGI -s /tmp/.fcgi_hgwebdir -G webserved -M 0660 ./hgwebdir.fcgi

nginx の設定ファイルは以下のようになりました。
初めて try_files を使ってみましたが、設定がとてもシンプルになりますね。
hgwebdir は PATH_INFO を利用してブラウズするリポジトリを探すようなので、その部分の置き換えにちょっと手を入れています。

server {
    listen       80;
    server_name  hg.example.com;
    root   /path/to/public;
    index  index.html;

    access_log  /var/log/nginx/hg-access.log  main;

    location / {
        try_files $uri @hgweb;
    }

    location @hgweb {
        fastcgi_pass   unix:/tmp/.fcgi_hgwebdir;
        fastcgi_read_timeout    5m;
        set $path_info "";
        if ($fastcgi_script_name ~ "^/(.*)$") {
            set $path_info $1;
        }
        fastcgi_param PATH_INFO $path_info;
    }
}

OpenSolarisで64bitのnginxをビルドする

bg — Thu, 04 Feb 2010 09:05:29 +0000

nginxの新しいバージョン(0.7.65)がリリースされていたので，バージョンアップしてみました。

しばらく前に見つかっていたSSLの脆弱製の実験をやろうと、久しぶりに SSL を有効にしたバイナリを作ろうとしたのですが，オプションの設定の仕方を忘れていて苦労しました。また、忘れても大丈夫なようにメモ。

OpenSolaris 2009.06 に含まれるOpenSSLは 0.9.8a と古いので、現時点での最新バージョンであるopenssl-0.9.8lをダウンロードしてきて使いました。今回はSNI(Server Name Indication)を有効にしたいのでenable-tlsextオプションを渡しています。

./config --prefix=/usr/local no-shared enable-tlsext
make
pfexec make install

これだけでもビルドは出来るのですが，OpenSolaris 2009.06 のデフォルトの GCC 3.2.3 ではなく新しい /usr/bin/gcc-4.3.2 を使いたいので，少し手を入れています。

export CC=/usr/bin/gcc-4.3.2
export CFLAGS='-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -march=native -O3 -Wall -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM'
./Configure --prefix=/usr/local no-shared enable-tlsext solaris64-x86_64-gcc
make
pfexec make install

export CC=/usr/bin/gcc-4.3.2した後にconfigスクリプトを実行すると，solaris64-x86_64-gcc-4.3.2 みたいな os:compiler になってエラーになってしまうんですよね。回避方法を探すのに手間取ってしまいました。

次に nginx のビルドですが，普通に configure を実行すると 32bit のバイナリが出来てしまいますので、gcc に渡すオプションも configure に渡します。

./configure --prefix=/usr/local --with-http_stub_status_module --with-http_gzip_static_module --with-http_ssl_module --with-cc=/usr/bin/gcc-4.3.2 --with-cc-opt='-m64 -march=native -O3 -I/usr/local/include ' --with-cpu-opt=amd64 --with-ld-opt='-m64 -L/usr/local/lib -L/usr/lib/amd64'
make
pfexec make install

ビルドした内容を確認

$ file /usr/local/sbin/nginx
/usr/local/sbin/nginx:  ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, stripped

$ /usr/local/sbin/nginx -V
nginx version: nginx/0.7.65
built by gcc 4.3.2 (GCC)
TLS SNI support enabled
configure arguments: --prefix=/opt/local --with-http_stub_status_module --with-http_gzip_static_module --with-http_ssl_module --with-cc=/usr/bin/gcc-4.3.2 --with-cc-opt='-m64 -march=native -O3 -I/usr/local/include' --with-cpu-opt=amd64 --with-ld-opt='-m64 -L/usr/local/lib -L/usr/lib/amd64'

SNIも有効になっています

zfsとタイムスライダーでハマった事

bg — Tue, 29 Sep 2009 10:09:41 +0000

今回の秋の連休は有休も使って9連休にしていました。
休み明けのボケた頭では仕事にならないので、午前中は開発用サーバたちのパッケージのアップデートをしていたところ、その中の１つにログインできませんでした。

そのホストは OpenSolaris 2009.06 の中に立てた Linux Branded Zone（BrandZ と書いた方がいいのかな）にインストールした CentOS3 でした。Solaris の Zone なので、ホストOS の方からは自由に Linux のファイルシステムに入っていけます。中のファイルを調べたところ、ログファイルの１つが46GB以上に肥大化してしまってディスクの残り容量が無くなってしまっているのが原因のようでした。

これなら、巨大化したログファイルを削除すれば問題解決だな、と軽い気持ちでrm ログファイル を実行したところ、意外な結果が戻ってきました。

cannot delete file: no space left on device.

ディスクに空き領域が無いからファイルを消したいのに、空き領域が無いからファイルを消せないと言われても。。。

ファイルシステムが壊れているのかと zpool scrub を実行してもエラーは無し。

Google 先生に質問してみたところ、zfs の既知のバグのようでした。曰く、ディスクの残り容量が無くなるとスナップショットが存在するファイルは削除できない。スナップショットの無いファイルを消して空き領域を作るか、スナップショットを削除すればよいようです。

が、zfs は使っているもののスナップショットなんて取ったことはありません。
不思議に思い zfs list -t snapshotを実行したところ、以下のように大量のスナップショットが存在していました。

rpool/ROOT/OpenSolaris-200906-090928@2009-07-10-00:41:02                      17.4M      -  2.85G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-10-17:54     39.5K      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-10-17:54      40K      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:monthly-2009-07-10-17:54   1.11M      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-11-00:00     3.67M      -  6.94G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-12-00:00     2.86M      -  7.14G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-13-00:00     5.29M      -  7.14G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-14-00:00     21.1M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-15-00:00    1.29M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-16-00:00      528K      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-17-00:00     3.73M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-18-00:00     1.67M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-19-00:00     1.05M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-20-00:00     1.08M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-21-00:00     1.22M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-22-00:00    1.35M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-23-00:00     1.35M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-24-00:00     5.91M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-25-00:00     5.93M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-26-00:00     5.87M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-27-00:00     6.60M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-28-00:00     6.42M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-11:00    1.73M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-12:00    1.71M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-13:00    1.93M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-14:00    1.88M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-15:00    1.79M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-16:00    1.26M      -  7.40G  -
...

犯人（？）は zfs の自動スナップショット機能でした。たしかにインストール直後に試しにタイムスライダーを有効にしたことがありましたが、こんな事になるとは。

大量のスナップショットを削除するようにシェルスクリプトを作成して問題は解決しました。ただ、ググっている時に「rpool の容量がなくなるとリブートもできなくなる」のような話もあったので、タイムスライダー（自動スナップショット）はちょっと恐くて使えないなぁ。