ラベル FreeBSD の投稿を表示しています。 すべての投稿を表示
ラベル FreeBSD の投稿を表示しています。 すべての投稿を表示

2019年6月17日月曜日

UTF-8で書かれた日本語テキスト, テキストファイルをPostScriptに変換する方法(2019/11)

gnome-u2ps があったのですが開発が停滞しており、debianからはパッケージがREMOVEDになってしまい、その後……(2019/11/4 gnome-u2psに関する追記あり)

・gedit からファイルに印刷する

geditでテキストファイルを表示してファイルに印刷する、という方法があります。 CLI操作が苦手って方がよくやるようです。 psもpdfも作れるようですので、重宝している方も結構いらっしゃるのかも?

・paps (+nkf)

UTF-8で書かれたテキストファイルを pango ライブラリ を用いてレンダリングし、 PostScriptファイルにするフィルタです。 debian のパッケージにはUTF-8で書かれた多言語テキストファイルの例(/usr/share/doc/paps/examples/small-hello.utf8)があり、これを変換してみると便利さがよく分かります。

sample-hello.utf8 には日本語の半角カナが含まれるのですが、これがきちんと半角カナのまま変換されるのは、なかなか強力ですね。
レンダリングをpapsがやり、元となる文字列が何であったかという情報を含みません。そのため、ps2txtでテキスト部分だけ引っ張り出す、みたいなことも出来ません。pdfもにおいても、本文をpdfリーダーで取り出せないものが出来ます。

印字フォントを変更するには、fontconfig で認識しているものを使いますが、文字サイズの変更だけでも受け付けるようです。デフォルトは "Monospace 12"となっていますが、実体はシステムによって微妙に違うでしょう。

日本語のテキストファイルを印字する場合は nkf を併用します。nkf --guessを使って UTF-8(LF)などと返ってくるなら、そのまま変換すればよいですが、それ以外の場合はパイプを使ってしまえばよいでしょう。

DebianにもUbuntuにもパッケージがあり、これが一番安定しているようです。RHELのナレッジベースでも紹介されていますね。


・nkf + e2ps

 e2psにはバグが多いのですが、それでもdebianパッケージなどに入っていることから利用者が若干いらっしゃるようです。e2ps は EUC-JP を受け付けて PostScript を作るものなのでnkf -edなどとした変換が必要になります。

・nkf + a2ps-j (Perl版a2ps)

 日本語テキストファイルをPostScriptにするプログラムには他にも a2ps-j (a2ps perl版) がありますが、perl 4時代のスクリプトなので、MacPortsや各種BSDパッケージなどではパッチを当てたり、色々対応しながらやってらっしゃる方もおられるようです。

https://svnweb.freebsd.org/ports/head/japanese/a2ps/
https://www.uconst.org/blog/archives/437

 個人的に注目しているのが、a2ps-j をUTF-8対応させる、以下のブログのパッチです。開発者さんにおかれましては、このパッチのライセンスを再利用しやすいものに設定していただけますと、各OSでのパッケージとして採用が進むと思いますので、何卒よろしくお願いしたいです。

a2ps Japanese UTF-8 patch (日本語 UTF-8 パッチ)
http://zyushimatsu.cocolog-nifty.com/blog/2014/12/a2ps-japanese-u.html

 なお、GNU a2ps や GNU enscript は日本語がダメそうなままです。つらい。

 (2019/11/4) コメントいただいておりました。
gnome-u2ps が gitlab で復活しているようです。
https://gitlab.com/gnomify/u2ps

で、この記事では紹介していませんでしたが、実は u2ps には数年前に同じ名前で別の人が作ったものがあるんです。
https://gitlab.com/arsv/u2ps

そう考えると、gnome-u2ps は u2ps-gtk とかにしたほうがいいような気もしますね。(ngraph-gtk 的なネーミングセンス……)

2019年5月13日月曜日

e2ps の修正パッチを一段落させた

 Linux などで日本語テキストファイルをPostScript形式に変換するソフトウェアの一つに e2ps があるのですが、いろいろバグが多くて困っており、一昨年くらいからちまちまと直したりしていました。
http://taraijpn.blogspot.com/2017/06/e2pspatch.html

 とりあえず Debian BTS で公開されているバグを直すところまで出来たので改めて紹介します。修正点は以下の通り。
  • フォントリストの文字型配列がコンパイル不能な書き方だった点を修正。
    • 各ディストリビューションで対応されています。
  • 用紙サイズのポイント数を PostScript の仕様で使われている数に合わせて修正。
    • 一部ディストリビューションで対応されています。
  • 生成される PostScript が EPS だった問題などを修正。
    • これでようやく fixps に怒られずに済みます。
  • 出力したページ数が誤っていた問題を修正。
    • ja_JP.EUC-JP 環境以外で動いているときに起こる問題でした。
  • ヌル文字から始まるテキストファイルが与えられるとクラッシュする問題を修正。
    • これは  https://bugs.debian.org/715852 で報告されていたものです。ヌル文字しかない、もしくはヌル文字から始まる(という意地の悪い)テキストファイルを印刷しようとすると起こる問題です。
  • 複数のファイルをまとめて変換すると、他のファイルの印刷末尾に余計な文字列が含まれる問題を修正。malloc を全て calloc に書き換えた。
    • e2ps README.euc README.english などとして出来たファイルを見たとき気づきました。環境依存?
  • Letterサイズで2面付け(-p2, -l2)を行うと用紙をオーバーする問題を修正。
    • 用紙のアスペクト比を維持するか、アスペクト比を歪めて紙面を広く使うか、どちらか悩んだ結果、前者を取りました。本来であればマージンを調整すべきところなのですが、それは全ての用紙サイズで考えないといけないことなので棚上げ。
  • PostScript の作者 ( %%Creator: ) は e2ps であるものとした。
    • CREATOR は help で使ってたので手を入れました。

 以上の内容を、patch1 として公開しました。(2019/5/14 patch1タグを打ってあります。
https://gist.githubusercontent.com/taraijpn/ea10ff9e908befafab7cff719f26dd20/raw/9a4a6fd502958a0e87db364174cbc331d07055be/e2ps-4.34.patch


 実はもう少しやらないといけないことがあって、
  • 変数の型を整理する。
    • unsigned char を使わないようにする。そもそも string.h で読んでいる関数と合わず warning が出ます。
    • unsigned char や signed char といった型は使わないようにして、コンパイラの警告をなくす。
  • 読み込めるファイルサイズを制限する。(2GB程度の予定)
    • unsigned long を size_t に直したらえらいことになったので。
 機械的な置き換えで問題ないかと思ったのですが、そんなに甘くなかった。sjisの変換に失敗する、とか、READMEにある他アーキテクチャ対応に悪影響が及びそうな気がするので、ちょっと止めてあります。とりあえず patch1 の上流での採用を目指したいところ。

 なお上流への連絡は、WebページにあるCGIで掲示板への書き込みやメールの送信を試みましたがいずれもエラーで動かず、2015年に公開されていたWindowsのプログラムにあるreadmeにメールアドレスが掲載されていたので、そこに送っています。果たして無事届いていますでしょうか……

2017年6月5日月曜日

e2psのpatchを作ってみた

日本語を含むテキストファイルを PostScript形式に変換するプログラムの一つに、 e2ps があります。LinuxのディストリビューションやFreeBSDなどにもパッケージがあったりしますね。

オリジナル: http://wtpage.info/wtseries/unix.html#e2ps
Debian: https://packages.debian.org/ja/stretch/e2ps
FreeBSD: http://www.freshports.org/japanese/e2ps/

で、色々あってこれを使ってみたのですが、どうにも動きがおかしい。
というわけで patch を作ってみたわけです。
https://gist.github.com/taraijpn/ea10ff9e908befafab7cff719f26dd20

どれくらい需要があるのか分かりませんが、とりあえず公開しておきます。

何がおかしかったかは以下の通り。

1)出力ページ枚数のカウントがおかしい。
2ページ以上になっても「One page was outputed」になる。1ページのときは「 1 pages were outputed.」って何故に複数形??

2)複数ページを出力するPostScriptなのに、何故かEPSだと言い張る。
おかげで psset に出来上がったファイルを渡すと、(pssetが内部で呼んでいる) fixpsから「fixps: DSC broken.  gs will be asked a full rewrite of the file.」と言われ、正しいPostScriptと認識されず、きちんと動かない。

3)内部で持っている用紙のサイズ(ポイント数)がおかしい。
なんでこんな数値にしたんだろう。複数面付けするときの計算の事情?

4)オリジナルのソースコードで何故かコンパイルが通らない(うちでだけ?)
ps-font.c に、gsFonts という静的配列の宣言があるのですが、さすがにこれはコンパイル通らないんじゃあ……でもFreeBSD portsmonでは何故かビルド出来てる……何故だ……
http://portsmon.freebsd.org/portoverview.py?category=japanese&portname=e2ps
※FreeBSDの ports では、ps-font.c の内容を修正するための sed コマンドが Makefile 側に書かれていました。どおりで files/ の中を見ても分からないわけだよ!
buildしたログで気づきました orz

===>  Patching for ja-e2ps-4.34
===>  Applying FreeBSD patches for ja-e2ps-4.34
/usr/bin/sed -i.bak -e '/Times-Roman$/,/^Gothic-Medium.Katakana$/{s,$,\\,;}' /usr/ports/japanese/e2ps/work/e2ps-4.34/ps-font.c


続き:https://taraijpn.blogspot.com/2019/05/e2ps.html

2013年7月18日木曜日

FreeBSD/amd64 9系でzfs(+nfs) を使いメモリ不足に陥る

FreeBSD 9.0-RELEASE(amd64)にzfsでファイルシステムを構築し、職場のPCのサーバとして使っていたのですが、先日サーバがメモリ不足の症状でダウンしまして、なんだこりゃ?と。USBキーボードの抜き差しすら対応出来なくなるという。おそろしや…

どうも目一杯vfs.zfs.arc_maxまでカーネルメモリを使い込んだようで、他のサービスにおけるメモリ使用とぶつかってしまっていたようです。さらに、職場のサーバはLinux機をクライアントに持っていて、ユーザの /home/ 領域をnfsでサービスしています。9.0-RELEASEのzfsにはnfsを利用するとメモリリークが起きる、というバグがあり、9.1-RELEASEでは修正されています。(事実誤認してたかも知れないので削除。)というわけで、
・OSをFreeBSD 9.1-RELEASEへ更新 (freebsd-updateでさっと更新。楽でした。)
・zfsのメモリ利用量を見直す
という対応を取りました。

昨今のLinux機のデスクトップ環境(特にブラウザ類)はホームディレクトリへのアクセスが頻繁に起こりますので、zfsのarc利用頻度が高く、nfsもメモリを使います。あとWeeklyのcronが走った後もarcにメモリが大量に使われた形跡がありました。locatedbの作成かなにかでしょうか。

FreeBSD 9.1-RELEASE (amd64) ではメモリのチューニングがよく行われていて、8GBのメモリを搭載したPCでは目一杯メモリをzfs、特にarcで使うような設定が施されているように見えます。例えばこんな感じ。(sysctl -a で確認)

        kern.maxusers:                          384
        vm.kmem_size:                           8216244224
        vfs.zfs.arc_min:                        892812800
        vfs.zfs.arc_max:                        7142502400

ARC以外1GBもあれば足りるでしょ、みたいな実にギリギリを攻めるパラメータ。
しかしそれでは怖い。かなり。というわけで、/boot/loader.conf に

vfs.zfs.arc_max="5120M"

の記述を追加し、少しメモリに余裕が出来るようにしてみました。本体8GBですからファイルシステム以外の部分に3GB、と考えれば大丈夫、のはず。Xも使ってないし。


        kern.maxusers:                          384
        vm.kmem_size:                           8216244224
        vfs.zfs.arc_min:                        671088640
        vfs.zfs.arc_max:                        5368709120

数日稼働させて、zfs-stats -M の実行結果はこんな数値。
(zfs-stats は ports にあります。)

System Memory:

        0.26%   20.27   MiB Active,     1.52%   118.75  MiB Inact
        71.22%  5.45    GiB Wired,      0.00%   0 Cache
        27.00%  2.07    GiB Free,       0.01%   736.00  KiB Gap

        Real Installed:                         8.00    GiB
        Real Available:                 98.93%  7.91    GiB
        Real Managed:                   96.68%  7.65    GiB

        Logical Total:                          8.00    GiB
        Logical Used:                   72.73%  5.82    GiB
        Logical Free:                   27.27%  2.18    GiB

Kernel Memory:                                  3.49    GiB
        Data:                           99.41%  3.47    GiB
        Text:                           0.59%   21.19   MiB

Kernel Memory Map:                              7.57    GiB
        Size:                           40.64%  3.08    GiB
        Free:                           59.36%  4.49    GiB

ARC関係の数値だと

ARC Summary: (HEALTHY)
ARC Misc:
ARC Size:                               76.20%  3.81    GiB

となっているので、Logical Used が 5.82GiBに対して ARC Sizeが 3.81GiB ということは、ARC以外で約2GB使っている、ということですから、やはり /boot/loader.conf で vfs.zfs.arc_max を絞る設定はしておいたほうがよいみたいですね。しばらくこれでいってみたいと思います。

2013年4月4日木曜日

pkgngに移行しようかと思ったけどやめた話

手元のFreeBSD 9.0-RELEASE機で、pkgngを使ってみようかと思ったのですが、移行作業をしたあとリポジトリにアクセス出来ないことに気づき困っていたところ、wikiに
https://wiki.freebsd.org/pkgng#Availability_of_pkgs_for_Download
for the time being pre-compiled packages for pkgng are not available from any official FreeBSD repository.
などと書かれており大変残念な状況にあることが分かりました。例によって気づきの順番が逆です……

で、どうしたか。
なかったことにしました。
pkgngをportsからインストールしてpkg2ngを実行したときのメッセージにありましたね。
# cd /var/db/
# mv pkg pkg.ng
# mv pkg.bak pkg
# pkg_info -aI
en-freebsd-doc-20111014 Documentation from the FreeBSD Documentation Project
libffi-3.0.9        Foreign Function Interface
libyaml-0.1.4_1     A YAML 1.1 parser and emitter written in C
lv-4.51             Powerful Multilingual File Viewer
...
# pkg_delete pkg-1.0.11
#
普通に表示出来るし。普通に消せるし。よかったよかった。 /etc/make.conf もきちんと編集しなおしておきました。もう少し待とう。

2012年2月3日金曜日

zfs雑感

zfsの基本はハードディスクを論理的に利用する、すなわち物理ディスクとして利用する際に様々な工夫をこらして利用する、Linuxで言うところのLVM(論理ボリュームマネジメント)です。 ハードディスクとファイルシステムとの間には一段クッションが挟まり、例えば柔軟なハードディスク容量の割り当て、冗長性の確保、ドライブエラーに対処しやすい、などといった様々な恩恵が得られるわけです。

しかし、ファイルシステムの障害そのものがなくなるというわけではありません。zfsで何かしらの障害が発生した際は、使い慣れた ufs や FAT といった従来のファイルシステムで起こっていたものとは異なる種類の障害が発生する可能性が高いわけです。対処法はもはや物理的直感に頼れるものではなく、zfsに対する高度な知識と経験を必要とすることでしょう。(ここでいう物理的直感に頼る対処法とは、例えば破損セクタのみを無理矢理読み飛ばす dd_rescue のような対処法のことを指します。)

そのため、zfsにしたからといってバックアップを怠ってはならないのです。 幸いなことに、zfsのバックアップ/リストア自体は比較的容易に出来るようになっているので、うまく活用しましょう。もちろんファイルシステムに依存しないバックアップ方法や運用の経験も十分活かせます。

 ……というのが、まあこのへんとかこのへんとかの話を読んで思ったことでした。そんな感想文。

2012年1月12日木曜日

FreeBSD 9.0-R系をこっそり入れてみた。

職場に2台あるサーバ機 (DELL PowerEdge SC440) に入れてみました。
ATAがCAMに統合された都合で、SATA HDDのマウント番号が不思議なことになっています。
PC1% dmesg | grep ada
ada0 at ata2 bus 0 scbus1 target 0 lun 0
ada0: <WDC WD800AAJS-18TDA1 01.00A04> ATA-7 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada0: 76293MB (156250000 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4
ada1 at ata2 bus 0 scbus1 target 1 lun 0
ada1: <INTEL SSDSA2CW160G3 4PC10362> ATA-8 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada1: 78125MB (160000000 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad5
ada2 at ata3 bus 0 scbus2 target 0 lun 0
ada2: <Hitachi HDS721010CLA332 JP4OA3MA> ATA-8 SATA 2.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada2: Previously was known as ad6
ada3 at ata3 bus 0 scbus2 target 1 lun 0
ada3: <Hitachi HDS721010CLA332 JP4OA3MA> ATA-8 SATA 2.x device
ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada3: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
ada3: Previously was known as ad7
Trying to mount root from ufs:/dev/ada0p2 [rw]...
PC2% dmesg | grep ada
ada0 at ata2 bus 0 scbus1 target 0 lun 0
ada0: <WDC WD800AAJS-18TDA1 01.00A04> ATA-7 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada0: 76293MB (156250000 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4
ada1 at ata3 bus 0 scbus2 target 0 lun 0
ada1: <ST3500630NS 3.AEG> ATA-7 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad6
ada2 at ata3 bus 0 scbus2 target 1 lun 0
ada2: <ST3500630NS 3.AEG> ATA-7 SATA 2.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
ada2: Previously was known as ad7
Trying to mount root from ufs:/dev/ada0p2 [rw]...

PC1には4ポートあるSATAすべてにHDD(SSD)が搭載されていて、PC2は4ポート中1ポートが空いている状況なのですが、ada0~3 と ada0~2 という具合に連番になっていますね。
PC2のほうでは、ada0, 2, 3 になるのかと思ってました……
関係しそうな GENERIC カーネルの設定はこれかな?
device          ahci            # AHCI-compatible SATA controllers
device          ata             # Legacy ATA/SATA controllers
options         ATA_CAM         # Handle legacy controllers with CAM
options         ATA_STATIC_ID   # Static device numbering
ATA_STATIC_IDついてるのに……そういうものなんでしょうか。

2011年4月28日木曜日

ports の net/samba35 が微妙に古い

FreeBSD ports に入っている samba 3.5系 (net/samba35) がどういう訳か 3.5.6 のままなのですね。
samba 3.5系の最新版は現在 3.5.8 なわけで。これはよろしくない、ってんで検証を一切していないまま、無理矢理最新版をコンパイルするような patch を作ってみました。
diff -urN net/samba35.orig/Makefile net/samba35/Makefile
--- net/samba35.orig/Makefile 2011-04-11 22:22:12.708685727 +0900
+++ net/samba35/Makefile 2011-04-26 19:28:16.125102303 +0900
@@ -6,8 +6,8 @@
#

PORTNAME= ${SAMBA_BASENAME}35
-PORTVERSION= 3.5.6
-PORTREVISION?= 2
+PORTVERSION= 3.5.8
+PORTREVISION?= 1
CATEGORIES?= net
MASTER_SITES= ${MASTER_SITE_SAMBA}
MASTER_SITE_SUBDIR= . old-versions rc pre
@@ -18,8 +18,8 @@

CONFLICTS?= *samba3[0-4]-3.* sharity-light-1.*
# Additional patches from Sernet.de
-PATCH_STRIP= -p1
-EXTRA_PATCHES= ${PATCHDIR}/sernet.patch
+#PATCH_STRIP= -p1
+#EXTRA_PATCHES= ${PATCHDIR}/sernet.patch

LICENSE= GPLv3
LICENSE_FILE= ${WRKDIR}/${DISTNAME}/COPYING
diff -urN net/samba35.orig/distinfo net/samba35/distinfo
--- net/samba35.orig/distinfo 2011-01-13 14:55:07.821352212 +0900
+++ net/samba35/distinfo 2011-04-26 16:52:06.184280759 +0900
@@ -1,2 +1,2 @@
-SHA256 (samba-3.5.6.tar.gz) = 466410868375d19a286ac3fc5d9f3c267ce359189f8e0d76e72ec10bd54247da
-SIZE (samba-3.5.6.tar.gz) = 30803319
+SHA256 (samba-3.5.8.tar.gz) = 331e3f2806edcad853b48f4b1e653367ad9a6ce1ab5ed486c03a6bf614882796
+SIZE (samba-3.5.8.tar.gz) = 30721269
お察しの通り、ほぼ distinfo を更新しただけです。EXTRA PATCHES はバグフィクスされたかどうか分からないので一旦保留にしてあります。
手元でコンパイルしてみると、出るわ出るわwarning...

% uname -mrs
FreeBSD 8.2-RC3 amd64
% grep warning samba358log.txt
configure.in:1402: warning: AC_CACHE_VAL(smb_attr_cv_xattr_add_opt, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:3353: warning: AC_CACHE_VAL(smb_ldap_cv_ldap_set_rebind_proc, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:3734: warning: AC_CACHE_VAL(smb_krb5_cv_ticket_has_keyinfo, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:3758: warning: AC_CACHE_VAL(smb_krb5_cv_creds_opt_free_context, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:3778: warning: AC_CACHE_VAL(smb_krb5_cv_verify_checksum, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:4120: warning: AC_CACHE_VAL(smb_krb5_cv_enctype_to_string_takes_krb5_context_arg, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:4141: warning: AC_CACHE_VAL(smb_krb5_cv_enctype_to_string_takes_size_t_arg, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:5597: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
samba4.m4:6: warning: file `../m4/check_python.m4' included several times
../lib/util/xattr.m4:9: warning: AC_CACHE_VAL(smb_attr_cv_xattr_add_opt, ...): suspicious cache-id, must contain _cv_ to be cached
samba4.m4:83: warning: file `../lib/tdb/libtdb.m4' included several times
../lib/tevent/samba.m4:3: warning: file `../lib/tevent/libtevent.m4' included several times
configure.in:1402: warning: AC_CACHE_VAL(smb_attr_cv_xattr_add_opt, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:3353: warning: AC_CACHE_VAL(smb_ldap_cv_ldap_set_rebind_proc, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:3734: warning: AC_CACHE_VAL(smb_krb5_cv_ticket_has_keyinfo, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:3758: warning: AC_CACHE_VAL(smb_krb5_cv_creds_opt_free_context, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:3778: warning: AC_CACHE_VAL(smb_krb5_cv_verify_checksum, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:4120: warning: AC_CACHE_VAL(smb_krb5_cv_enctype_to_string_takes_krb5_context_arg, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:4141: warning: AC_CACHE_VAL(smb_krb5_cv_enctype_to_string_takes_size_t_arg, ...): suspicious cache-id, must contain _cv_ to be cached
configure.in:5597: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
samba4.m4:6: warning: file `../m4/check_python.m4' included several times
../lib/util/xattr.m4:9: warning: AC_CACHE_VAL(smb_attr_cv_xattr_add_opt, ...): suspicious cache-id, must contain _cv_ to be cached
samba4.m4:83: warning: file `../lib/tdb/libtdb.m4' included several times
../lib/tevent/samba.m4:3: warning: file `../lib/tevent/libtevent.m4' included several times
modules/vfs_zfsacl.c:285: warning: initialization from incompatible pointer type
modules/vfs_zfsacl.c:287: warning: initialization from incompatible pointer type

追いかけはじめるとハマりそうなので、ログを出しておくだけでそっとしておこうかと思います……
むしろ、files/ の下にある大量のpatch はすんなり当たっているのがなんともかんとも。

2011年2月13日日曜日

Debian/kFreeBSDのメモ

先日 Debian/kFreeBSD が正式リリースされましたね。まだ試せてないんですが、ちょっと読んだりしてるところをメモしておこうと思います。

http://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ
FAQですね。翻訳は無いです。FAQの中で面白いなあと思ったのはこれ。
Q. What version of kFreeBSD is supported?
A. The squeeze release is based on the 8.1 kernel, see for details.
If you are interested, you can take a look at the patches Debian applied to the kernel.
http://svn.debian.org/wsvn/glibc-bsd/trunk/kfreebsd-8/debian/patches/999_config.diff
 あれ、NIC の fxp とか bce は無いの?とか、

http://svn.debian.org/wsvn/glibc-bsd/trunk/kfreebsd-8/debian/patches/903_disable_non-free_drivers.diff
 なるほど、Highpoint RocketRAID ( hptrr, hptmv ) とか NVIDIA nForce MCP Networking Adapter ( nve ) はnon-freeなのか。知らなかった…とか。

ちゃんとインストールした後にどうなってるか見ておきたいですね。

2011年2月2日水曜日

FreeBSD 8.2-RC3に更新した(実機編)

使用中のPC(core i7-860/ P55 chipset)を8.0-RELEASE-p4(amd64)から 8.0-RELEASE-p6に更新したところ、

kernel: interrupt storm detected on "irq19:"; throttling interrupt source

を頻発するようになったのが、今回8.2-RC3に更新しようと思ったきっかけです。
vmstat -i で見たところ、原因は

interrupt total rate
irq19: atapci0+++ 29162 7

上記の例は8.2-RC3の場合なのですが、8.0-RELEASE-p6のときは、ここの割り込み数がトータルで10桁以上になっており、rateも7桁以上の数字になっていました。(うろ覚え)

調べた結果、Intel 5系のチップセットに対応するのは 8.2-RELEASEからのようで。じゃあ今まで何故平気だったのかというと、どういう訳かICH8として認識してたようです。

8.0-RELEASE-p4 までは ICH8 として認識していたのですが、8.0-RELEASE-p6 にした時点でatapciの認識がSATAじゃないコントローラとして認識したようで、そこで扱いが狂ってinterrupt stormが起こっていると判断した、のかな?(8.0-RELEASE-p6にした後、interrupt stormが頻発するので BIOSで AHCI を切ったかも知れません。)

データ領域にzfsを使っているのですが、8.0から8.2に上がるとzfsのバージョンが上がるため、作業として問題ないのかどうか確かめたのが、先日書いたブログの内容でした。

実機での移行は問題なく終了しました。先日書いたブログでは、8.2-RC3更新後に py-zfs を入れる、と書きましたが、更新し忘れたまま zfs upgrade しても問題なく動いていました。何だったんだろう…

2011年2月1日火曜日

FreeBSD 8.0→8.2に伴いzfsを更新してみる

FreeBSD 8.0で構築したzfsを、FreeBSD 8.2にupgradeした際に正しく更新することは出来るのか? という話です。zfsbootとか複雑なことをしていない限り、あっさり更新出来るはず。ちょっとvmware上で試してみました。

FreeBSD 8.0-RELEASE (i386) の環境構築


まず8.0-RELEASEを入れ、カーネルをリコンパイルします。GENERICに書くので /usr/src を make update したときは注意すること。

options KVA_PAGES=512

次にzfsを有効にする。(vmware)

vm.kmem_size="768M"
vm.kmem_size_max="768M"
vfs.zfs.arc_max="80M"

そして

# bsdlabel /dev/ad0s1
# /dev/ad0s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 1048576 0 4.2BSD 0 0 0
b: 6223488 1048576 swap
c: 41942817 0 unused 0 0 # "raw" part, don't edit
d: 5208064 7272064 4.2BSD 0 0 0
e: 1048576 12480128 4.2BSD 0 0 0
f: 8388608 13528704 4.2BSD 0 0 0
g: 20025505 21917312 4.2BSD 0 0 0
# bsdlabel /dev/ad1
bsdlabel: /dev/ad1: no valid label found

ad0s1g と ad1 がzfspool候補。

# zpool create zp0 ad0s1g
# zpool create zp1 ad1

# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
zp0 9.50G 72K 9.50G 0% ONLINE -
zp1 7.94G 72K 7.94G 0% ONLINE -

こうなる。

# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad0s1a 507630 208682 258338 45% /
devfs 1 1 0 100% /dev
/dev/ad0s1e 507630 12 467008 0% /tmp
/dev/ad0s1f 4058062 2226374 1507044 60% /usr
/dev/ad0s1d 2521070 37264 2282122 2% /var
zp0 9805696 0 9805696 0% /zp0
zp1 8192896 0 8192896 0% /zp1

/usr/src, /usr/portsをzfsに置いておく。

# cd /usr
# tar -cpf - src | ( cd /zp0/ ; tar -xf - )
# tar -cpf - ports | ( cd /zp1/ ; tar -xf - )
# mv ports ports.orig
# ln -s /zp0/src src
# ln -s /zp1/ports ports

これで試行準備完了。

ここからFreeBSD 8.2

RELENG_8_2 に更新。/usr/src/Makefileの教えに従い滞りなく終了。sysutils/py-zfs は8.2に上げてから導入or更新。

Before:(8.0-RELEASE-p6)

%zpool status -v
pool: zp0
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp0 ONLINE 0 0 0
ad0s1g ONLINE 0 0 0

errors: No known data errors

pool: zp1
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp1 ONLINE 0 0 0
ad1 ONLINE 0 0 0

errors: No known data errors

%zpool upgrade
This system is currently running ZFS pool version 13.

All pools are formatted using this version.

%zfs upgrade
This system is currently running ZFS filesystem version 3.

All filesystems are formatted with the current version.

After:(8.2-RC3)

# zpool status -v
pool: zp0
state: ONLINE
status: The pool is formatted using an older on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on older software versions.
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp0 ONLINE 0 0 0
ad0s1g ONLINE 0 0 0

errors: No known data errors

pool: zp1
state: ONLINE
status: The pool is formatted using an older on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on older software versions.
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp1 ONLINE 0 0 0
ad1 ONLINE 0 0 0

errors: No known data errors

# zpool upgrade
This system is currently running ZFS pool version 15.

The following pools are out of date, and can be upgraded. After being
upgraded, these pools will no longer be accessible by older software versions.

VER POOL
--- ------------
13 zp0
13 zp1

Use 'zpool upgrade -v' for a list of available versions and their associated
features.

# zfs upgrade
This system is currently running ZFS filesystem version 4.

The following filesystems are out of date, and can be upgraded. After being
upgraded, these filesystems (and any 'zfs send' streams generated from
subsequent snapshots) will no longer be accessible by older software versions.


VER FILESYSTEM
--- ------------
3 zp0
3 zp1

ということでupgrade推奨されるので…(例によってバックアップはしっかりとりましょう)

# zfs upgrade -a
zp0: can not be upgraded; the pool version needs to first be upgraded
to version 15

zp1: can not be upgraded; the pool version needs to first be upgraded
to version 15

0 filesystems upgraded
これはzpoolのupgradeをする前に zfs をupgradeしようとしたのでエラーになった。順番が重要です。

# zpool upgrade -a
This system is currently running ZFS pool version 15.

Successfully upgraded 'zp0'

Successfully upgraded 'zp1'
数秒で終わる。

# zfs upgrade -a
2 filesystems upgraded
十数秒で終わる。

# zpool upgrade
This system is currently running ZFS pool version 15.

All pools are formatted using this version.

# zfs upgrade
This system is currently running ZFS filesystem version 4.

All filesystems are formatted with the current version.

# zpool status
pool: zp0
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp0 ONLINE 0 0 0
ad0s1g ONLINE 0 0 0

errors: No known data errors

pool: zp1
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
zp1 ONLINE 0 0 0
ad1 ONLINE 0 0 0

errors: No known data errors
かくて滞りなくOSの更新もzfsの更新も終了。


注意事項、というか、正直よく分かっていない事項として、8.0→8.2になった際に物理ドライブの位置が変更されてしまった場合に(ad0がad4になったり、別のデバイス名になったら)どうなるのだろう?という点。zfsとして読み込めていれば問題はないのでしょうか?

2010年1月9日土曜日

unixbench 5.1.2 を FreeBSD でもCPU数に応じて動くようにしてみる

unixbench 5.1.2 を使ってベンチマークをとっていたのですが、FreeBSDで実行するとCPU数を認識してくれず、少々寂しい結果になるので、patchを作ってみました。ついでに、コンパイラの情報も表示させるようにもしてみたので、そのpatchも置いておきます。(FreeBSD版のpatchはLinux版のpatchの内容を含んでいます。)

■FreeBSD用のpatch はこちら→ unixbench-5.1.2.FreeBSD.patch
□Linux用のpatch はこちら→unixbench-5.1.2.custom.patch

GNU make が必要です。


%ls
unixbench-5.1.2.FreeBSD.patch unixbench-5.1.2.tar.gz
%tar -xzf unixbench-5.1.2.tar.gz
%patch -p < unixbench-5.1.2.FreeBSD.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN unixbench-5.1.2.orig/Makefile unixbench-5.1.2/Makefile
|--- unixbench-5.1.2.orig/Makefile 2007-12-23 04:51:21.000000000 +0900
|+++ unixbench-5.1.2/Makefile 2010-01-10 16:11:10.219596811 +0900
--------------------------
Patching file unixbench-5.1.2/Makefile using Plan A...
Hunk #1 succeeded at 38.
Hunk #2 succeeded at 137.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN unixbench-5.1.2.orig/Run unixbench-5.1.2/Run
|--- unixbench-5.1.2.orig/Run 2007-12-23 06:48:10.000000000 +0900
|+++ unixbench-5.1.2/Run 2010-01-10 16:10:54.483552885 +0900
--------------------------
Patching file unixbench-5.1.2/Run using Plan A...
Hunk #1 succeeded at 62.
Hunk #2 succeeded at 80.
Hunk #3 succeeded at 681.
Hunk #4 succeeded at 723.
Hunk #5 succeeded at 734.
Hunk #6 succeeded at 796.
Hunk #7 succeeded at 1379.
Hunk #8 succeeded at 1582.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN unixbench-5.1.2.orig/Run_FreeBSD unixbench-5.1.2/Run_FreeBSD
|--- unixbench-5.1.2.orig/Run_FreeBSD 1970-01-01 09:00:00.000000000 +0900
|+++ unixbench-5.1.2/Run_FreeBSD 2010-01-10 16:10:09.484287187 +0900
--------------------------
(Creating file unixbench-5.1.2/Run_FreeBSD...)
Patching file unixbench-5.1.2/Run_FreeBSD using Plan A...
Hunk #1 succeeded at 1.
done
%cd unixbench-5.1.2
%vi Makefile
(Makefileを編集します。GMAKEに GNU make コマンドを設定してください。
 FreeBSDの場合は gmake になると思います。
 GRAPHIC_TESTS を切るかどうかはお好みで。FreeBSDで動くかどうかは試していません。
 CC で C コンパイラを変更できます。その場合は、後述の Run_FreeBSD を編集して下さい。)
%vi Run_FreeBSD
(ベンチマークをとる perl スクリプトです。Makefileでの記述を参考に、
my $gMake = 'gmake';
my $cCompiler = 'gcc';
 を書き換えてください。)
% gmake
% ./Run_FreeBSD
gmake all
gmake[1]: Entering directory `/home/tarai/unixbench-5.1.2'
Checking distribution of files
...
(ここからベンチマークを実行しますので、60分ほど放置するか、
screen などで逃げられるようにしておいたほうがいいでしょう)


./Run のかわりに ./Run_FreeBSD を実行すると、こんなふうにベンチマークが取れる、はず。

BYTE UNIX Benchmarks (Version 5.1.2-custom)

System: zitaku.localdomain: FreeBSD
OS: FreeBSD -- 8.0-RELEASE-p2 -- FreeBSD 8.0-RELEASE-p2 #0: Thu Jan 7 18:38:59 JST 2010 tarai@zitaku.localdomain:/usr/obj/usr/zsrc/sys/GENERIC
Machine: amd64 (GENERIC)
Language: en_US.utf8 (charmap=, collate=)
Compiler: gcc (GCC) 4.2.1 20070719 [FreeBSD]
CPU 0: hw.model: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (0.0 bogomips)

CPU 1: hw.model: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (0.0 bogomips)

CPU 2: hw.model: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (0.0 bogomips)

CPU 3: hw.model: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (0.0 bogomips)

CPU 4: hw.model: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (0.0 bogomips)

CPU 5: hw.model: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (0.0 bogomips)

CPU 6: hw.model: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (0.0 bogomips)

CPU 7: hw.model: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (0.0 bogomips)

1:41AM up 1 day, 6:44, 1 user, load averages: 0.00, 0.00, 0.00; runlevel

------------------------------------------------------------------------
Benchmark Run: 土 1 09 2010 01:41:48 - 02:13:24
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 19614465.7 lps (10.0 s, 7 samples)
Double-Precision Whetstone 4220.0 MWIPS (9.7 s, 7 samples)
Execl Throughput 3474.9 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 131206.9 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 33294.4 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 462368.5 KBps (30.0 s, 2 samples)
Pipe Throughput 1622117.6 lps (10.0 s, 7 samples)
Pipe-based Context Switching 248853.7 lps (10.0 s, 7 samples)
Process Creation 10993.0 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 7765.5 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 2535.4 lpm (60.0 s, 2 samples)
System Call Overhead 974418.6 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 19614465.7 1680.8
Double-Precision Whetstone 55.0 4220.0 767.3
Execl Throughput 43.0 3474.9 808.1
File Copy 1024 bufsize 2000 maxblocks 3960.0 131206.9 331.3
File Copy 256 bufsize 500 maxblocks 1655.0 33294.4 201.2
File Copy 4096 bufsize 8000 maxblocks 5800.0 462368.5 797.2
Pipe Throughput 12440.0 1622117.6 1304.0
Pipe-based Context Switching 4000.0 248853.7 622.1
Process Creation 126.0 10993.0 872.5
Shell Scripts (1 concurrent) 42.4 7765.5 1831.5
Shell Scripts (8 concurrent) 6.0 2535.4 4225.6
System Call Overhead 15000.0 974418.6 649.6
========
System Benchmarks Index Score 873.4


------------------------------------------------------------------------
Benchmark Run: 土 1 09 2010 02:13:24 - 02:42:59
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables 81213813.6 lps (10.0 s, 7 samples)
Double-Precision Whetstone 26264.1 MWIPS (9.9 s, 7 samples)
Execl Throughput 7712.6 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 93489.7 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 23754.0 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 371435.3 KBps (30.0 s, 2 samples)
Pipe Throughput 8691978.0 lps (10.0 s, 7 samples)
Pipe-based Context Switching 2075904.6 lps (10.0 s, 7 samples)
Process Creation 16325.9 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 21494.6 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 2922.0 lpm (60.1 s, 2 samples)
System Call Overhead 5527171.2 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 81213813.6 6959.2
Double-Precision Whetstone 55.0 26264.1 4775.3
Execl Throughput 43.0 7712.6 1793.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 93489.7 236.1
File Copy 256 bufsize 500 maxblocks 1655.0 23754.0 143.5
File Copy 4096 bufsize 8000 maxblocks 5800.0 371435.3 640.4
Pipe Throughput 12440.0 8691978.0 6987.1
Pipe-based Context Switching 4000.0 2075904.6 5189.8
Process Creation 126.0 16325.9 1295.7
Shell Scripts (1 concurrent) 42.4 21494.6 5069.5
Shell Scripts (8 concurrent) 6.0 2922.0 4870.0
System Call Overhead 15000.0 5527171.2 3684.8
========
System Benchmarks Index Score 2050.6





以下説明。patchを当てずに実行すると、

BYTE UNIX Benchmarks (Version 5.1.2)

System: zitaku.localdomain: FreeBSD
OS: FreeBSD -- 8.0-RELEASE-p2 -- FreeBSD 8.0-RELEASE-p2 #0: Thu Jan 7 18:38:59 JST 2010 tarai@zitaku.localdomain:/usr/obj/usr/zsrc/sys/GENERIC
Machine: amd64 (GENERIC)
Language: ja_JP.utf8 (charmap=, collate=)
CPU: no details available
12:28AM up 1 day, 5:30, 1 user, load averages: 0.00, 0.00, 0.00; runlevel

ベンチマークの結果も 1CPUのときのみを計測して終わってしまいます。これはつまらない。

理由は、Run スクリプトが Linux 決め打ちのコードになっていて、CPUに関する情報を
/proc/cpuinfo から取っているためです。Linux エミュレーションを入れていれば、おそらくその絶対パスを書き換えるだけでいいと思うのですが、たまたま手元のマシンにはLinux エミュレーションを入れていなかったので、perlの勉強がてら、sysctlから取るようにしてみました。

sysctl の情報しか取り出していないので、bogomips や CPUの機能情報は決め打ちで埋めてます。CPUの個数さえ分かれば SMP の時のベンチマークも取るようになるので、これで十分かなと思っています。これ以上の情報を取ろうとすると cpuid とかのお世話にならないといけないのかな?

NetBSD, OpenBSD, PC-BSD などの場合は、sysctl のキーが同じなら、Run_FreeBSD のスクリプトを見て場合分けを書き換えればいけると思います。手元にないので確認は取れてません。

Linux エミュレーションが有効な場合は、./Run にある $pCpuinfo="/proc/cpuinfo" を書き換えれば ./Run でも実行できると思います。そういうふうに書き換えてはおきましたが、動作は未確認です。

実は Compiler 情報も表示するよう改造していたり、本家 Run スクリプトも、ハードコーディングしている部分を書き換えたりしているので、これをそのまま ports パッチにするのは改変の度が過ぎると思います。(バージョン情報もちょっといじっています。)Run_FreeBSD のファイルを抜いたものを本家に提出して、もし本家に採用されたら、そこから USE_GMAKE=YES, USE_LINUX=YES という条件で ports を作るのが綺麗な気がしますけど、需要があるのかどうか……

2009年12月1日火曜日

print/cups-base の更新がうまくいかない…

portupgrade -a をちょっとやってみたのですが、 print/cups-base のアップグレード (cups-base-1.3.9_3 から 1.4.2 へ)に失敗してしまいました。


cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler -L/usr/local/lib/ -L/usr/local/lib -Wl,-R/usr/local/lib -pie -fPIE -Wall -Wno-format-y2k -fPIC -Os -g -fstack-protector -o cupsd auth.o banners.o cert.o classes.o client.o conf.o dirsvc.o env.o main.o ipp.o listen.o job.o log.o network.o policy.o printers.o process.o quotas.o removefile.o select.o server.o statbuf.o subscriptions.o sysman.o -L. -lcupsmime \
-lz -L/usr/local/lib -lgnutls -lldap -lpam \
-lpaper -L/usr/local/lib -ldbus-1 -lcups -L/usr/local/lib -lgnutls -pthread -lm -lcrypt \

client.o(.text+0x233a): In function `encrypt_client':
/usr/ports/print/cups-base/work/cups-1.4.2/scheduler/client.c:3217: undefined reference to `_httpReadGNUTLS'
client.o(.text+0x234e):/usr/ports/print/cups-base/work/cups-1.4.2/scheduler/client.c:3218: undefined reference to `_httpWriteGNUTLS'
gmake[1]: *** [cupsd] エラー 1
gmake[1]: ディレクトリ `/usr/ports/print/cups-base/work/cups-1.4.2/scheduler' から出ます
gmake: *** [all] エラー 1
*** Error code 1

Stop in /usr/ports/print/cups-base.
*** Error code 1

Stop in /usr/ports/print/cups-base.
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20091130-71145-r2vh1l-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=cups-base-1.3.9_3 UPGRADE_PORT_VER=1.3.9_3 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! print/cups-base (cups-base-1.3.9_3) (linker error)


他にも同様の問題が報告されていたり、既にsend-prされている(ports/141014)みたいなので、しばらく動向を見守るなり、対策が思いつく方はcommitしてみて下さい。どうもDBUSへの対応を切るといいみたいなんですが、それはgnomeで使うときに問題にならないんだろうか……?

で、終わっとく予定だったんですが、ついかっとなって調べた。正直おなかが空いている。

引っかかっている原因は、どうも
/usr/ports/print/cups-base/work/cups-1.4.2/cups/http.c
のコンパイルが行われていないせいなのではないか? という気がします。

というのは、上記ソースに _httpReadGNUTLS() が含まれているのですが、
/usr/ports/print/cups-base/ で make して止まったとき、
/usr/ports/print/cups-base/work/cups-1.4.2/cups/lib*
には _httpReadGNUTLS() が含まれていないのです。だからリンク時エラーが出てるんですね。

で、script を使って make 時のログを見てみたんですが、どうも http.c がコンパイルされていないようなんです。(何故?)

エラーで止まった状態で
/usr/ports/print/cups-base/work/cups-1.4.2/cups
まで下がり、 make testhttp を実行した後だと、
# grep _httpReadGNUTLS lib*
Binary file libcups.a matches
で無事 _httpReadGNUTLS() が含まれるようになります。このときのログにはちゃんと、

echo Compiling http.c...
Compiling http.c...
cc -Wall -Wno-format-y2k -fPIC -Os -g -fstack-protector -I.. -D_CUPS_SOURCE -I/
usr/local/include/avahi-compat-libdns_sd/ -I/usr/local/include -I/usr/local/incl
ude/avahi-compat-libdns_sd/ -O2 -fno-strict-aliasing -pipe -DLDAP_DEPRECATED -I
/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -DDBUS_API_S
UBJECT_TO_CHANGE -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_THREAD_SAFE -D_REENTRANT -c http.c
echo Compiling http-addr.c...
Compiling http-addr.c...
cc -Wall -Wno-format-y2k -fPIC -Os -g -fstack-protector -I.. -D_CUPS_SOURCE -I/
usr/local/include/avahi-compat-libdns_sd/ -I/usr/local/include -I/usr/local/incl
ude/avahi-compat-libdns_sd/ -O2 -fno-strict-aliasing -pipe -DLDAP_DEPRECATED -I
/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -DDBUS_API_S
UBJECT_TO_CHANGE -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_THREAD_SAFE -D_REENTRANT -c http-addr.c

といったようなログが残っています。ところが、ports で make したときにはこれが無い。

多分Makefileの違いなのだろうと思うんですが……なんでだろう?

追記:とりあえず解決? Makefileのほうで置き換えをしていたようです。こんな感じになおすとmakeが通るようになりました。


# diff -u print/cups-base/Makefile.orig print/cups-base/Makefile
--- print/cups-base/Makefile.orig 2009-12-01 22:53:29.000000000 +0900
+++ print/cups-base/Makefile 2009-12-01 22:56:09.000000000 +0900
@@ -261,7 +261,7 @@
${WRKSRC}/Makefile
.else
@${REINPLACE_CMD} \
- -e 's|cups filter backend|backend|' \
+ -e 's|cups filter backend|cups backend|' \
-e 's|$$.INSTALL_SCRIPT. cups-config|echo skip: cups-config|' \
-e 's|/usr/share|${PREFIX}/share|g' \
-e 's|installhdrs$$||' \


本家にも報告しておいたけど、合ってるのかな……?

2009年10月9日金曜日

page fault while in kernel mode ??


ハードディスクの全セクタ検査をやっている間、VMware Workstation で実験環境を作ってみたのですが、gmirrorしたディスクの上でzfsを動かすと、何故かリブートの度に gm0 のrebuildが走ってしまい、起動時にzfsプロセスがpage fault を起こす、という、GEOMなのかzfsなのかVMware Workstationなのか原因がはっきりしないトラブルに見舞われました。とりあえず記録。あやしいことをやっていることは確かなのです(^^;

環境:VMware Workstation 6.5.3 build-185404
ホストOS: Microsoft Windows Server 'Longhorn' Business 6.0.6002, Service Pack 2 (32bit)
ゲストOS: FreeBSD/amd64 8.0-RC1 (64bit)

やったこと:
仮想メモリ1536MBの仮想PCを作成。それに30GBの仮想ドライブを2台(da0, da1)作成し接続。
うち1台(da0)にFreeBSD/amd64 を "User" インストールする。
ただし、OSのインストールには10GB程度しか使わず、残り20GBは空けておく。
OSインストール終了後、FreeBSD ハンドブックを参考にしてgmirrorでミラーリングする。
(zfsを使うよう /boot/loader.conf や /etc/rc.conf を書き換えておく。)
ミラーリング出来たら、空き容量のある mirror/gm0s1 に見えるので、
# gpart add -b xxxxx -s xxxxxx -t freebsd-zfs
で空いてる部分を mirror/gm0s1g として作成する。
この mirror/gm0s1g を使って、zfsの領域を作成、適宜マウントする。
# zpool create tank mirror/gm0s1g
# zfs create tank/home
# zfs create tank/export
# zfs create tank/ulocal
# mkdir /home /export
# zfs set mountpoint=/home tank/home
# zfs set mountpoint=/export tank/export
# zfs set mountpoint=/usr/local tank/ulocal
# zfs set mountpoint=none tank

このあたりはいろいろなサイトに載っている普通の手順かと思います。
が、どういう訳かここで再起動すると、上記スクリーンショットのようなFatal errorが起きます。原因はよく分かりません。さて、実機でも同様なことが起こるのでしょうか……?

2009年10月8日木曜日

結局HDD障害だったようです。

先日からatacontrolでRAID1が構築出来なかった件ですが、その後 gmirror に乗り換えてみたところ……


ad16: FAILURE - READ_DMA status=51 error=40 LBA=93492224
GEOM_MIRROR: Request failed (error=5). ad16[READ(offset=47868018688, length=131072)]
GEOM_MIRROR: Synchronization request failed (error=5). mirror/gm0[READ(offset=47868018688, length=131072)]

というわけで、どうやらHDD障害だったようです。

カーネルパニックを起こしたatacontrolと違い、こんなエラーがあってもmirrorを続けるgmirrorはすごいですね。しかしこれでは使えない。エラーがあると思われる領域は /usr にあり、/usr/src を展開しようとしたら、その作業が止まってしまいました。

ディスクがエラーで使えないと分かったら即座にOfflineにするatacontrolの振る舞いも理解出来るんですが、まさかその使えないディスクを元にして懸命にrebuildしてたとは思わなかったようです。

mhddでチェックしたところ、当該部分はUNCとしてXがついてました。ただ、mhddがError:として返してきた位置は 93492434 なんですが、atacontrolのときやgmirrorのときに返された値とは若干ずれてます。やはりHDDとしてダメだったというこなのでしょう。ディスク障害に備えて新品のHDDで環境を構築しようとしたら、その前段階でコケるとは。

ところでmhddのフルスキャン、1TBのディスクをチェックするのに3時間弱かかります。で、とりあえずチェックしないといけないHDDは3本。これは……また帰りが遅くなりそうです。

2009年10月7日水曜日

atacontrolでRAID1を作り直す→失敗してデータ消失?

先日PCを新調しました。
Intel Core i7-860 + GIGABYTE GA-P55-UD3R という新しめのハードに、FreeBSD/amd64 8.0-RC1 という挑戦的な仕様です。(dmesgは後日。)

で、実験がてら、ICH10Rの機能でRAID1を組み、一端FreeBSDをインストール。その後、ケーブルを抜いてみてRAID1をDEGRADEさせ、そこから復旧させようと思ったのですが……

ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode
ar0: 953867MB status: DEGRADED
ar0: disk0 READY (master) using ad16 at ata8-master
ar0: disk1 DOWN no device found for this subdisk

起動時にこんな感じにメッセージが出ると、RAID1がおかしくなっている証拠。

# atacontrol status ar0
ar0: ATA RAID1 status: DEGRADED
subdisks:
0 ad16 ONLINE
1 ---- MISSING (←実際の障害の内容でここは書き換わると思います。)
# atacontrol list (ダメになったディスクがどのataチャンネルにあったか見る。)
ATA channel 9:
Master: no device present (抜いたディスクは本来ここにあった。)
Slave: no device present
# atacontrol detach ata9 (この例ではata9になる。) 
電源を切ってディスク交換。ホットスワップでもいいのかな?
# atacontrol attach ata9 (必要ないかも?)
Master: ad18 SATA revision 2.x
Slave: no device present
# atacontrol status ar0
ar0: ATA RAID1 status: DEGRADED
subdisks:
0 ad16 ONLINE
1 ---- MISSING (ないことになっている)
# atacontrol addspare ar0 ad18
# atacontrol status ar0
ar0: ATA RAID1 status: DEGRADED
subdisks:
0 ad16 ONLINE
1 ad18 SPARE  (スペア扱いになる)
# atacontrol rebuild ar0 (指示出しだけなので一瞬で終わる。)
# atacontrol status ar0
ar0: ATA RAID1 status: REBUILDING 0% completed
subdisks:
0 ad16 ONLINE
1 ad18 SPARE

この処理をマルチユーザモードでやっており、リビルド作業をインターネット経由で行っていました。リビルドコマンドを投入した後、viでちょっとしたスクリプトを書いていたところ、ファイルをセーブしたところでフリーズ。

コンソール画面を見ると、

......
g_vfs_done():ar0s1a[WRITE(offset=1348632576, length=16384)]error = 5
g_vfs_done():ar0s1a[WRITE(offset=1348698112, length=16384)]error = 5
g_vfs_done():ar0s1a[WRITE(offset=1541259264, length=16384)]error = 5
g_vfs_done():ar0s1a[WRITE(offset=2311831552, length=16384)]error = 5
g_vfs_done():ar0s1a[WRITE(offset=2697117696, length=16384)]error = 5
g_vfs_done():ar0s1a[WRITE(offset=3082403840, length=16384)]error = 5
panic: initiate_write_inodeblock_ufs2: already started
g_vfs_done():cpuid = 0
ar0s1d[WRITE(offset=65536, length=2048)]Uptime: error = 5
47m24s
Cannot dump. Device not defined or unavailable.
Automatic reboot in 15 seconds - press a key on the console to about

落ちてました。リビルドはシングルユーザモードでやったほうがいいということでしょうか。

で、もう一度RAID1を構成しなおしOSを入れ、今度はシングルユーザモードで試してみました。

# zfs umount -a   (zfsのほうからマウント解除)
# umount -a     (ufsのほうをマウント解除)
# atacontrol detach ata9
# atacontrol attach ata9 (意図的にDEGRADEさせる)
# atacontrol addspare ar0 ad18
# atacontrol rebuild ar0
(とここまでは手順通り)
# echo "ttt" >> /test.txt
# echo "ttt" >> /test.txt   つい魔が差してやってしまった。
# echo "ttt" >> /test.txt
# sync
# atacontrol status ar0
ar0; ATA RAID1 status: REBUILDING 1% completed
subdisks:
0 ad16 ONLINE
1 ad18 SPARE
# (放置後数分経過)
ad16: FAILURE - READ_DMA status=51 error=40 LBA=93492352
ar0: FAILURE - RAID1 array broken
ad18: WARNING - WRITE_DMA taskqueue timeout - completing request directly
atacontrol: read: Input/Output error
WARNING - WRITE_DMA48 freeing taskqueue zombie request
リビルドに失敗してBROKEN扱いです……

なお、困ったことに、こうなってから再起動した後で、BIOSのRAID調整メニューから見たときドライブが Offline Member になっていると、RAID1は破損。リビルドは絶望的なようです。再マウントしてデータを取り出せるかどうかは分かりません。あまりに危険な状況なので、もし試される場合はお手元の余りHDDでお試し下さい。

次こそは悪戯せずにrebuildに挑戦…と思いましたが、台風が近いので帰ることにします。

2009年10月6日火曜日

続:FreeBSDのdump -Lってzfsに対応してますか?

昨晩書いた話の続きなんですが、一晩よく寝て改めて確認してみたら、いくつか勘違いしていることに気づきました。話を整理しましょう。

まず、dumpは伝統的に ファイルシステム単位でバックアップするものであり、tarやrsyncなどのようなファイル単位でのバックアップツールではないこと。
よって、ファイルシステムが異なる場合は、それに対応するダンプ用のコマンドを用いるのが適切であること。例えばSolarisであればufsdump/ufsrestoreという名前になっている。

zfs send は snapshotをダンプするコマンドであること。よってdump -Lとは扱いが異なる(バックアップ前に手動でsnapshotを作る作業が必要?)。dumpと同様に標準出力やファイルへの書き込みが可能なので、バックアップ先のファイルシステムは問わない。ただしFreeBSD 8.0RC1のマニュアルには
The format of the stream is evolving. No backwards compatibility is
guaranteed. You may not be able to receive your streams on future
versions of ZFS.
などと書いてあるのでOSのメジャーアップデートの際は気をつけましょう。

実際のところ、FreeBSDのdumpはzfsに対応していません。FreeBSD/amd64 8.0-RC1で実行しようとすると。

# df /home
Filesystem 1K-blocks Used Avail Capacity Mounted on
zfstank/home 850525952 58368 850467584 0% /home
basil# dump -0aLu -f /backup/home-amd64-091006.zfsdump /home
DUMP: WARNING: Cannot use -L on an unmounted filesystem.
dump: /home: unknown file system
という結果となりました。そりゃ、そうか。素直に zfs sendを使いましょう。

何故dumpにこだわるのかというと、FreeBSDにはchflags (Linuxで言うとchattr)で調整できる拡張ファイル属性があり、これがバックアップ作業に影響することがあるため。例えばrsyncなどでうまく処理出来なかったりします。

というわけで、先日のエントリで無知を晒したわけですが、いつものことなので気にしない分からなくなったらとりあえず寝てから整理する、というのは重要ですね、ということで。

debian/ubuntuでは dump パッケージを導入します。それでも ext2/3 までの対応で、snapshotを取ってダンプする機能があるようには見えませんでした。FreeBSD dump でufs2をダンプしたものを Linux restore でext2/3に移動出来るかは分かりません。他のファイルシステムについては、ext4についてはdump/restore可xfsはxfsdump/xfsrestoreがある、btrfsはよく分かりません。開発中?

2009年10月5日月曜日

FreeBSD の dump -L ってzfsに対応してますか?

職場PCを新調する機会があり、HDDを増設し、FreeBSD 8.0-RC1 を導入しました。

もののついでに、ちょっとバックアップ体制について見直したのですが、最近は dump(8) に -L オプションなるものがついていて、これを実行すると、丁寧にも一端スナップショットを取得してからdumpする、という振る舞いを見せます。つまりシングルユーザモードに落ちなくても稼働中にdumpが出来るというわけです。これはかなり便利。

ところが、このスナップショットを取得する部分が、ファイルシステムが巨大(100GB以上?)になると途端に処理が重くなります。どうも、ufs2のスナップショットを取得する /sbin/mksnap_ffs に原因があるようです。

http://www.freebsd.org/cgi/query-pr.cgi?pr=111782
600GBくらいのファイルシステムを-Lでダンプしようとするとおかしくなる?(6.x系列)
mksnap_ffs time
シリンダグループの数が多すぎると遅くなる、らしい。

そこで、最近流行の zfs に乗り換えれば、もしかしたらスナップショットの取得も早くなり、dumpも気軽に出来るのかな、と思ったのですが、ここでふと疑問。dumpオプションの-Lは zfs に対応しているのでしょうか?

(バックアップ元のファイルシステムが zfs であるときに、バックアップ先のHDDもzfsにして、zfs send/receive を使うのが筋としては適切、というのは分かるのですが、バックアップ先のHDDがzfsではない、とか、実は未だにテープを愛用している、とか、dump系のシェルスクリプトを書き直すのがちょっとなあ……等といった状況を想定しています。)

dump(8) は -L オプションが実行されると、スナップショットを取得するコマンドを用いるのですが、コードを見ると……
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dump/main.c?rev=1.67.2.1;content-type=text%2Fplain

char snapname[BUFSIZ], snapcmd[BUFSIZ];

snprintf(snapname, sizeof snapname, "%s/.snap", mntpt);
if ((stat(snapname, &sb) < 0) || !S_ISDIR(sb.st_mode)) {
msg("WARNING: %s %s\n",
"-L requested but snapshot location",
snapname);
msg(" %s: %s\n",
"is not a directory",
"dump downgraded, -L ignored");
snapdump = 0;
} else {
snprintf(snapname, sizeof snapname,
"%s/.snap/dump_snapshot", mntpt);
snprintf(snapcmd, sizeof snapcmd, "%s %s %s",
_PATH_MKSNAP_FFS, mntpt, snapname);
unlink(snapname);
if (system(snapcmd) != 0)
errx(X_STARTUP, "Cannot create %s: %s\n",
snapname, strerror(errno));
if ((diskfd = open(snapname, O_RDONLY)) < 0) {
unlink(snapname);
errx(X_STARTUP, "Cannot open %s: %s\n",
snapname, strerror(errno));
}
unlink(snapname);
if (fstat(diskfd, &sb) != 0)
err(X_STARTUP, "%s: stat", snapname);
spcl.c_date = _time_to_time64(sb.st_mtime);
}

ここでスナップショットを取得するコマンドが _PATH_MKSNAP_FFSとして定義されているようです。これ、どこにあるのかというと…
http://www.freebsd.org/cgi/cvsweb.cgi/src/include/paths.h?rev=1.28.2.1;content-type=text%2Fplain

#define _PATH_MKSNAP_FFS "/sbin/mksnap_ffs"

これ。で、このソースを見ると、
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/mksnap_ffs/mksnap_ffs.c?rev=1.10.2.1;content-type=text%2Fplain

読み切れませんでしたorz

とりあえず、zfsだからといって zfs snapshot を使っているようにも見えず、正直よく分からないのですが、さて、zfsのファイルシステムを dump -L でダンプすることは出来るのでしょうか? それとも、zfsだと実はわざわざスナップショットを取る必要がない、とか?

追記:後日談を書きました。

2009年5月12日火曜日

Optionsの怪

FreeBSD portsからアプリケーションをインストールしようとして、時折困ることがあります。というのは『make時のオプションの意味がわからない』こと。インストールしようとするアプリケーションの知識が中途半端な時『何故このオプションがあるのだろう?』というのが分からなかったりするのです。

そんな状態でports使ってアプリケーション入れたら危険だろう、とか、いろいろあることは分かっているのですが……

例えばsubversionだとこんな感じ。

│ Options for subversion 1.6.2  │
│ ┌────────────────────────────────┐ │
│ │ [ ] MOD_DAV_SVN mod_dav_svn module for Apache 2.X │ │
│ │ [ ] APACHE2_APR Use APR from Apache 2.X │ │
│ │ [ ] MOD_DONTDOTHAT mod_dontdothat for Apache 2.X │ │
│ │ [X] NEON WebDAV/Delta-V repo access module (neon) │ │
│ │ [ ] SERF WebDAV/Delta-V repo access module (serf) │ │
│ │ [ ] SASL SASL2 authorization support │ │
│ │ [X] BDB db4 repository backend │ │
│ │ [ ] ASVN Build and install Archive SVN (asvn) │ │
│ │ [ ] MAINTAINER_DEBUG Build debug version │ │
│ │ [ ] SVNSERVE_WRAPPER Enable svnserve wrapper │ │
│ │ [ ] STATIC Build static version (no shared libs) │ │
│ │ [X] BOOK Install the Subversion Book │ │

これ"だけ"を見て全部のオプションが何を意図していて、何故必要か分かりますか?

こういうときは、Makefile をきちんと読んで、オプションの有無でmakeがどのような動きをするのかを追いかける、というのが、多分正しい手順なんだろうと思います。が、時々これがきついなあと思うことがあるのです。歳だから?とか言わない。

make configの画面だけ切り出して、wikiみたいなところでオプションの解説してくれるようなサービスとかがあったら面白いのかなあ。どうなのかなあ。portsメンテナさんの仕事が増えるだけでしょうか。

ぱっと見でオプションが多くなる理由は、多分なんですが、
・関連するアプリと連携を取る必要があると増える
・OS固有の環境に合わせようとすると増える
・portsメンテナのサービス精神で増える?
みたいなところがあるのかな、と思っています。このあたり、他のOSではどういうふうに対処してるんでしょう。binary packageになってしまっているから、この辺の問題はあまり見えなくなっちゃってるんでしょうかね。

たまにはこういう雑感を書いてみるのもいいかと思い、メモしてみる次第です。

2009年4月24日金曜日

portupgradeがダメなときは基本に戻ろうという話。

忘れそうになるのでとりあえずメモ。

FreeBSD portsにある rtorrent を portupgrade で更新しようと思ったのですが、net/xmlrpc-c-devel のコンパイルに失敗しているようで……

cc -o xmlrpc xmlrpc.o srcdir/tools/lib/dumpvalue.o /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/lib/util/casprintf.o /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/lib/util/cmdline_parser.o /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/lib/util/getoptx.o /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/lib/util/stripcaseeq.o /usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/lib/util/string_parser.o -Lblddir/src -Lblddir/lib/libutil -lxmlrpc_client -lxmlrpc -lxmlrpc_util -L/usr/local/lib -lwwwxml -lxmltok -lxmlparse -lwwwzip -lwwwssl -lwwwinit -lwwwapp -lwwwhtml -lwwwtelnet -lwwwnews -lwwwhttp -lwwwmime -lwwwgopher -lwwwftp -lwwwfile -lwwwdir -lwwwcache -lwwwstream -lwwwmux -lwwwtrans -lwwwcore -lwwwutils -lmd5 -lz -L/usr/lib -lssl -lcrypto -L/usr/local/lib -lcurl -rpath=/usr/lib:/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lidn -lssh2 -lssl -lcrypto -lz -L/usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/lib/expat/xmlparse -lxmlrpc_xmlparse -L/usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/lib/expat/xmltok -lxmlrpc_xmltok
/usr/bin/ld: warning: libxmlrpc.so.14, needed by blddir/src/libxmlrpc_client.so, may conflict with libxmlrpc.so.3
blddir/src/libxmlrpc.so: undefined reference to `xmlrpc_XML_GetErrorString'
gmake[2]: *** [xmlrpc] エラー 1
gmake[2]: ディレクトリ `/usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/tools/xmlrpc' から出ます
gmake[1]: *** [xmlrpc/all] エラー 2
gmake[1]: ディレクトリ `/usr/ports/net/xmlrpc-c-devel/work/xmlrpc-c-1.18.00/tools' から出ます
gmake: *** [tools/all] エラー 2

こんな感じで止まります。ちなみに構築環境とMakefileのリビジョンは以下の通り。

# uname -mirs
FreeBSD 7.1-RELEASE-p5 i386 GENERIC
# grep '$FreeBSD:' Makefile
# $FreeBSD: ports/net/xmlrpc-c-devel/Makefile,v 1.38 2009/04/10 18:12:05 chinsan Exp $

ログを見てみると、既に入っている過去バージョンの libxmlrpc.so.3 が衝突している様子。(ldの優先順位が悪いんじゃあ…?) portupgrade は upgrade するときに対象をアンインストールせずに build するようです(?)。

で、ちょっと基本に立ち返ってみたら、あっさり解決しました。

# cd net/xmlrpc-c-devel
# make deinstall
(ここで依存しているパッケージの一覧が警告として出ます。)
# make
(今度はエラーなくbuild出来たようです)
# make install

その後、改めて portupgrade -rf rtorrent を実行すると、今度はうまくいきました。

buildするときに過去のパッケージがあると不都合が起きる、というのは意外だったのですが、こういうものなのでしょうか。ちょっと原因がはっきりしないので、エラーとして報告するのもどうかと思い、とりあえず書いておく次第です。