Samba の smbd 用の /service/smbd/run スクリプトは、 当初は次のようになっていた。 Linux, Solaris ではこれで何も問題なかった:

#!/bin/sh
exec 2>&1
exec envdir ./env sh -c '
  echo "PID: $$"
  env |sort |sed "s/^/Environment: /"
  set -- \
    argv0 \
    "$COMMAND" \
    "${ARGV0:-sv:`pwd`}" \
    --daemon \
    --foreground \
    ${CONFIGFILE:+"--configfile=$CONFIGFILE"} \
    ${PORT:+"--port=$PORT"} \
    ${LOGLEVEL:+"--debuglevel=$LOGLEVEL"} \
    ${LOGDIR:+"--log-basename=$LOGDIR"} \
    ;
  echo "Execute: $@"
  exec "$@"
'

ところが、某お客さんから、 AIX 6 上で smbd の子プロセスが defunct (ゾンビ) 化するという問題が報告された。 会社の AIX 環境で試したところ、数回に一回程度しか発生しないが、 smbd を起動した直後に発生することがわかった。 発生したときの状態は次のような感じ:

# /opt/osstech/sbin/service osstech-smb status
/opt/osstech/etc/svscan/smbd (pid 270496) is running...
# ps -ef |grep 270496 |grep -v grep
    root 270496 258182   0 13:07:27      -  0:00 sv:/var/opt/osstech/lib/sv/smbd --daemon --foreground
    root 282806 270496   0 13:07:27      -  0:00 sv:/var/opt/osstech/lib/sv/smbd --daemon --foreground
    root 295074 270496   0                  0:00 <defunct>

smbd は起動直後にプリンタキュー監視用の子プロセスを生成するので、 これ関連のバグかと思ったが、 ps で見たときちゃんと 2つの smbd が存在するので問題ないように見えた。 smbd を手動で直接起動すると発生しないし、 truss でシステムコールを見たところ、ほかに子プロセスを生成している様子はない。

suerpvise か run スクリプトが怪しいと思い、run スクリプトを色々変更してみたところ、 「env |sort |sed 's/^/Environment: /'」 の行をコメントアウトすると再現しないことがわかった。 ということは、パイプライン中のプロセスのいずれかが看取られずに残っているらしい。

また、/bin/sh ではなく bash, zsh, zsh の ksh 互換モードでは再現しないことがわかった。 ちなみに、AIX 6 の /bin/sh は AT&T 由来の Korn Shell (ksh93)。

パイプラインの実行後にそのプロセスが残るのが問題であると推測し、 試行錯誤した結果、次のようなスクリプトで再現することに成功した。 これで、パイプライン実行後に、 実行中の ksh の子プロセスがゾンビ化していることが確認できる:

$ while :;do /bin/ksh -c '/bin/true|/bin/true; ps -f -u $LOGNAME"';done |grep '[d]efunct'
    root 688354 712836   0                  0:00 <defunct>
    ...

Linux の /bin/ksh (ksh93)、Solaris 10 の /bin/ksh (ksh88) でも再現した。 bash, zsh, ash はもちろん、Linux 上の pdksh (バブリックドメイン版の ksh 実装) でも再現しなかった。AT&T ksh の仕様らしい。

つまり、こういうこと:

1. ksh は「env |sort |sed "s/^/Environment: /"」を実行したとき、 パイプラインの最後のプロセス (sed) が終了した時点で以降のスクリプトの実行に進む。 パイプライン前段のプロセス (env, sort) の終了は待たない。
2. その後のスクリプト実行中、以前実行したパイプライン前段のプロセスが終了した場合、 ksh はそれを wait(2) して看取る。
3. ksh は smbd に exec(2) する。
4. smbd になった時点で以前実行したパイプライン前段のプロセスが残っていた場合、 それが終了したとき、wait(2) で看取るのは親プロセスである smbd プロセスの役目となる。 しかし smbd はそのことを知らないので wait(2) することはなく、 結果、子プロセスはゾンビ化する。

ksh がパイプライン前段のプロセス終了をどのようなタイミングで、 どのように処理するかまでは確認していないけど、だいたいこんな感じだと思う。

というわけで、run スクリプトは次のようになった。 違いは exec の前に wait を挿入しただけ:

#!/bin/sh
exec 2>&1
exec envdir ./env sh -c '
  echo "PID: $$"
  env |sort |sed "s/^/Environment: /"
  set -- \
    argv0 \
    "$COMMAND" \
    "${ARGV0:-sv:`pwd`}" \
    --daemon \
    --foreground \
    ${CONFIGFILE:+"--configfile=$CONFIGFILE"} \
    ${PORT:+"--port=$PORT"} \
    ${LOGLEVEL:+"--debuglevel=$LOGLEVEL"} \
    ${LOGDIR:+"--log-basename=$LOGDIR"} \
    ;
  ## ksh: Ensure that all commands in the pipeline are terminated
  wait
  echo "Execute: $@"
  exec "$@"
'

これで無事に問題解決。

シェルスクリプト中ではパイプラインはもちろん、 exec も常用するたちなので、これは困った仕様だなぁ。 exec 前に wait すべし…なんて、バッドノウハウもいいところ。

まずは Windows 上での操作。試したのは Windows Server 2003R2 と Windows 3.2.8。

C:\> net use \\samba\share /user:fumiyas
...
C:\> fsutil file createnew \\samba\share\file.txt 1000000000
ファイル \\samba\share\file.txt が作成されました

Samba ホスト上で確認してみる。見た目のサイズは 1GB だが、実際のサイズは 0。

$ ls -l /srv/share/file.txt
-rw-rw-r-- 1 fumiyas Domain Users 1000000000 2009-06-03 20:52 /srv/share/file.txt
$ du -sk /srv/share/file.txt
0       /srv/share/file.txt

Windows からファイルに追記してみる。

C:\> echo foo >>\\samba\share\file.txt

再び Samba ホスト上で確認してみる。

$ ls -l /srv/share/file.txt
-rw-rw-r-- 1 fumiyas Domain Users 1000000006 2009-06-03 20:52 /srv/share/file.txt
$ du -sk /srv/share/file.txt
12      /srv/share/file.txt

2009-06-11 追記: smb.conf で strict allocate = yes (デフォルト: no) を設定して追試したところ、 sparse file にならなかった。うーん。 fsutil の sparse サブコマンドでどうにかするのだろうか?

http://gitweb.samba.org/?p=samba.git;a=commit;h=bca371bff8e1dd5099eda1774e5bb0fdbd6a1a77

これで Samba のハックがしやすくなるかな? Samba 3.0 との差分が多くなってしまったので、 Samba 3.0.24 向けに作成した OSSTech ローカルパッチを Samba 3.2 向けに直すのが大変そうな予感もする…。

my $sid_bin = $entry->get_value('objectSid');
my ($sid_rev, $sid_sub_auths_num, $sid_reserved, $sid_id_auth, @sid_sub_auths) =
  unpack('C2nNV*', $sid_bin);
my $sid = sprintf(
  'S-%u-%u' . '-%u' x $sid_sub_auths_num,
  $sid_rev, $sid_id_auth, @sid_sub_auths
);

2009-07-10: コードを修正。 SID テキストの 3 番目の文字は subauthority の数 ($sid_sub_auths_num) ではなく identifiter-authority ($sid_id_auth) だった。

今日のバグは libsmbclient の smbctelldirctx() が出鱈目なオフセット値を返す、でした。

#!/usr/bin/ruby -w


IPC class with external command

class CmdIPC
attrreader :reader, :writer
def initialize(command, *args, &ipcproc)
if command.class == Array
@command, @arg0 = command
else
@command = @arg0 = command
end
@args = args
@ipcproc = ipcproc
@pid = nil
startcommand
end
def startcommand
@reader, cwriter = IO.pipe
c_reader, @writer = IO.pipe

Parent process returns here

return if @pid = fork

Child process

begin
@reader.close
@writer.close
STDIN.reopen(creader)
STDOUT.reopen(cwriter)
creader.close
cwriter.close
exec([@command, @arg0], @args)
rescue => e
raise "cannot execute external command: #{@command}: #{e}"
end
end
def stopcommand
if @pid
@reader.close
@writer.close
Process.kill('TERM', @pid)
Process.waitpid(@pid)
end
@pid = nil
end
def restartcommand
stopcommand
startcommand
end
def ipc(input)
@ipcproc.call(self, input)
end
end
if FILE == $0
lookupsid = CmdIPC.new('/usr/bin/rpcclient', '-U%', '-d0', '127.0.0.1') {
|sid, reader, writer|
writer.puts("lookupsids #{sid}")
next unless line = reader.gets
next unless match = line.match(/^S(?:-\d+)+\s(.)\s+(\d+)$/)
next match[1]
}
puts lookupsid.ipc('S-1-1-0')
puts lookupsid.ipc('S-1-3-0')
puts lookupsid.ipc('S-1-3-1')
end

注意: この実装では、出力をバッファリングするコマンドに対しては利用できない。

(まだ素人なので)この実装がオブジェクト指向的 (Ruby 的) に美しいかどうかはよくわからないが、 参考書を片手に数分でそれっぽいのが完成してしまった。 ちょっと感動した。 Ruby だとより直感的に書けるということかな。 ソフトウェア関係で感動したことは、過去、両手で足りる回数しか経験がないので、 貴重な体験だった。

一点気になるのは、CmdIPC.new に渡しているコードブロックには return 文が書けないこと。 Ruby のリファレンスを読めば理由は納得できるのだが、 next は違和感ありすぎ。 せめて break ならいいのだけど、 それだと LocalJumpError 例外が発生して break from proc-closure と文句を言われる。 何か間違っているのかなぁ?

実は Ruby の勉強と平行して Samba 共有内のファイル検索ツールを今月中に作らねばならないのだけど、間に合うかしら!? いや、間に合わせねば。 Ruby の素晴しさを引き出すには時間が足りないかもしれないけど、 そこそこは使い熟せそうな感触を得ている。

初 Ruby スクリプトは以下のような感じ。突っ込み歓迎。 Ruby/SMB を利用して SMB 共有内の特定の拡張子のファイルを一覧表示する Ruby スクリプト:

#!/usr/bin/ruby -w

require "smb"

## Override SMB::Dir::Entry#url to hide "user:password" in URL
class SMB::Dir::Entry
  alias original_url url
  private  riginal_url
  def url
    return original_url.sub(%r#^([^/:]+://)(?:[^/]+@)?#, '\1')
  end
end

$ext = %w(odt ods odp doc xls ppt pdf txt htm html)
$server = "127.0.0.1"
$user = "testuser"
$password = "testuserpassword"
$server.downcase!
$auth = [nil, $user, $password]
$ext_re = Regexp.new("\\.(#{$ext.join("|")})$", Regexp::IGNORECASE)

def crawl(dir)
  dir.direntries.each do |entry|
    next if entry.name =~ /^\.\.?$/
    ## FIXME: SIGSEGV protector (libsmbclient's bug?)
    next if entry.url.length > 1000
    if entry.file?
      if entry.url =~ $ext_re
        puts entry.url
      end
    elsif entry.dir?
      begin
        entry_dir = entry.open
        crawl(entry_dir)
      rescue => e
        e_message = e.to_s.sub(/ - smb:\/\/.*/, '')
        STDERR.puts "#{$0}: cannot open directory: #{entry.url}: #{e_message}"
      ensure
        entry_dir.close if entry_dir
      end
    end
  end
end

SMB.on_authentication do |server, share, workgroup, user, password|
  $auth
end

begin
  server = SMB.open("smb://#{$server}/")
  #server = SMB.open("smb://#{$user}:#{$password}@#{$server}/")
rescue => e
  STDERR.puts "#{$0}: cannot connect to server: #{$server}: #{e}"
  exit 1
end
server.direntries.each do |entry|
  if entry.file_share?
    begin
      entry_share = entry.open
      crawl(entry_share)
    rescue => e
      STDERR.puts "#{$0}: cannot connect to share: #{entry.name}: #{e}"
    ensure
      entry_share.close if entry_share
    end
  end
end

exit 0

以下は Ruby/SMB beta3 用のパッチで、 SMB.on_authentication のバグ修正とログレベルを 0 に変更する修正:

--- rubysmb-beta-3/rubysmb.c.dist   2002-10-17 20:13:48.000000000 +0900
+++ rubysmb-beta-3/rubysmb.c    2007-06-05 23:52:11.698527382 +0900
@@ -112,9 +112,9 @@ static void auth_fn(const char *server,
 if (RARRAY(ary)->len != 3) {
   rb_raise(eSmbError, "array should contain workgroup, username and password to use as authentication");
 }
-
-  wg = RARRAY(ary)->ptr[1];
-  un = RARRAY(ary)->ptr[0];
+
+  wg = RARRAY(ary)->ptr[0];
+  un = RARRAY(ary)->ptr[1];
   pw = RARRAY(ary)->ptr[2];
   if (!NIL_P(wg)) {
@@ -167,7 +167,7 @@ void Init_smb()
 {
   int err;
-  err = smbc_init(auth_fn, 1);
+  err = smbc_init(auth_fn, 0);
   if (err < 0) {
     rb_raise(rb_eRuntimeError, "Error loading libsmbclient: %s\n", strerror(errno));
   }

移行対象のファイルはおよそ 3TB あった。 移行元の OS が UNIX 系の場合、 Windows クライアントを介さずに直接 UNIX to UNIX でやったほうが絶対に楽。 何かと融通が効くし、 クライアントを介さない分速いし、 ファイル属性を完全にコピーするのが簡単だし、 トラブルが発生しても解明するのが簡単だし、 rsync で差分同期可能といいことずくめ。 ただし、ファイル名の変換が必要な場合は難しい。

Mac OS X 上のファイル名は Decomposed UTF-8 (いわゆる UTF-8-MAC) だが、 一般的な UNIX なら Composed UTF-8 が通例。 いつも通りファイル移行には rsync を利用したが、 現在の rsync には残念ながらファイル名の変換機能がないので (rsync 3.0 で実装されるらしい)、 CentOS にコピーした後に Composed UTF-8 に変換する必要がある。 移行対象のファイルの数は膨大なので変換に結構な時間がかかるし、 rsync で最終同期をかけた後にしか実行できない。 そこで今回は、Samba の smb.conf で unix charset = UTF-8-MAC と設定することにした。

結果、別のところでトラブったが、ファイルのほうは問題なく移行できた。 ふつうの iconv(3) は UTF-8-MAC に対応していないので、 Mac OS X 上の Samba や OSS テクノロジ製の Samba と libiconv (UTF-8-MAC 対応) 以外では unix charset = UTF-8-MAC は使えないのでご注意を。

そのほかに、 Mac OS X クライアントが SMB 共有上に特殊な名前のファイルを作成するという問題がある。 veto files = /.DSStore/.*/ を設定すれば抑制できるが、Mac OS X からの通常の操作でエラーが発生してしまう。 ということで、Windows クライアントに対してのみ veto files を適用するようにして対処。

samba-technical メーリングリスト に投稿するだけでは無視されるか放置されてしまうことが多いので、 Bugzilla に登録するほうが確実みたい。