パスワードを忘れた？ アカウント作成
Close

FreeBSD 14.0-RELEASEと格闘開始 More | Reply

「FreeBSD 14.0-RELEASEと格闘開始」記事へのコメント

  • UNIX互換OS初心者です。
    LinuxにするかFreeBSDにするか迷ってます。

    経験者でもFreeBSDは難しいですか？

    • 他の方のコメントも参考にされて、好みと直感で
      「これに決めた！」で いいんじゃないでしょうか。

      「格闘」と書いたのは、バグや問題があったら
      自力でねじ伏せる つ も り で やっているからです。

      例えば ちょうど今、'setenv LC_CTYPE ja_JP.SJIS' な状態で 'printenv' すると
      tcsh が core 吐いて telnet 接続もろとも落ちる問題に直面中です。
      とりあえず "alias printenv 'printenv | cat'" しておくと (coreは吐くけど)
      telnet 接続は保持される(なんで？)ので当座はこれで誤魔化し、いずれ
      tcsh のソースを落として自分で debug するのでしょう、たぶん…。
      　(UTF-8 には絶対行かないし bash に移行もしない！)

      あと UNIX互換OS遣いを目指すなら まずは vim を習得しておいて
      損はないです。Mac なら Terminal.app で vim 使えるはずだし、
      win機でも cmd.exe ベースで行けます。
      　(私の vim環境構築方法等は こちら [aid.her.jp]に、古いけど)
      私は vim を使うために生きていて vim に生かされています。(古いけど)

      • Re: (スコア:0)

        by Anonymous Coward

        >tcsh が core 吐いて telnet 接続もろとも落ちる問題に直面中です。
        % file core
        を実行して、本当に core が tcsh 由来か見たほうが良いんじゃないかな、telnet のバグかもしれないし、端末の設定かもしれないし。

        • file名が tcsh.core なんで犯人は tcsh だと思われます。
          どうも tcsh が死んで、それは exit するのと同じなので
          telnet 接続が切れるのは至極当然なのですが、
          Tera Term のウィンドウが消えるので 情報もとれず
          とっちらかって「とんでもないことが起こった！」と
          パニクってたよう。(新しい環境は何もかも疑わしいから つい…)
          んで alias で パイプを使うと、(たぶん)サブシェルで実行されて
          死ぬのはサブシェルなので 親tcsh は生き残る、ような感触です。
          が、他が落ち着いたら色々よく見てみますね。

          # SAMBA の smbd が定期的に disk アクセスするようで
          # HDD が stand-by に行かないのが今の hottest topic!

          • ＜tcsh問題＞
            /usr/src/tools/tools/locale/etc/final-maps/ の
            map.SJIS と map.eucJP で以下の違いがあり、
            　｜<YEN_SIGN> \x5c　⇔　<REVERSE_SOLIDUS> \x5c
            　｜<OVERLINE> \x7e　⇔　<TILDE> \x7e
            文字名を euc に倣った /usr/share/locale/ja_JP.SJIS/LC_CTYPE を作ったら
            落ちなくなりました。副次効果として、コマンドラインで '\' を打つと "\134"、
            '~' を打つと "\176" 表示となっていた問題と、prompt に cwd が '~' 表示
            されている際に コマンドラインの行編集でカーソルがずれる問題も解消。
            …本来は <YEN_SIGN> <OVERLINE> を正しく扱うように tcsh 側を直すべきだとは
            　思います。　（ちなみにソースは /usr/src/contrib/tcsh/ にあったわ）

            ＜smbd問題＞
            smbd は複数のデーモン間の通信に socket(/var/db/samba4/private/msg.sock/*) を
            使っており /var/db/samba4/ 以下を memory-disk に置き換えたら HDD が
            ちゃんと寝るようになった。（今ひとつ気に入らないが…）

            # smbd(v4.16.11)が死にまくるのと RealTek 用の re0 ドライバが
            # watchdog timeout しまくるのが 今の hottest topic!

            • ＜tcsh問題＞
              tcsh は NLSの isprint() 等の返す値に そのまま従っているだけ
              っぽい感触、話がシステムサイドに広がりそう。
              　(SJIS の '\','~' が print不可文字ってなるんだけど…)
              printenv で落ちる訳はまだ (/usr/src/... にソースはあったけど
              (個別の) Makefile がなくて make の仕方がわからない)

              ＜re0ドライバ問題＞
              RealTek社 御謹製の FreeBSD 用 re0ドライバってのが見つかって
              無理やり差し替えてみたら調子良さげ

              ＜smbd死亡問題＞
              samba416-4.16.11.pkg から samba413-4.13.17_6.pkg に
              乗り換えてみたけど 死ぬのは同じよう、ただここまで
              ファイルコピー失敗／ファイル破損には一切なっていない。
              　（Explorer から プロパティを取って ファイルカウント
              　　してる時に死ぬと誤報告になるよう）

              # 22個 計 330GB のテストファイル群を rm * するだけなのに
              # 90秒もかかるとか、現行 10.2R サーバーに比べて disk
              # アクセスが 1.5倍ぐらい遅いのが 今の hottest topic!

              • ＜tcsh問題＞
                bugzillaにProblem Report [freebsd.org]投げたら反応があった。

                ＜smbd死亡問題＞
                なんか書き込みは上位レイヤーでリトライしてエラーにならないけど、
                読み込みはあっさりエラーになるような感触、どうしたものか…

                そしてええかげんスラドのトップから消えて欲しいんだけど この日記…
                （ええ格好しい ちょっと疲れました）

                # rm * 90秒がまだ手付かずで hottest topic!

              • ＜rm * 90秒問題＞
                22ファイル 330GB の rm * が 90秒かかる問題は、UFS filesystem の
                soft update オプションの入れ忘れで、tunefs で ON にしたら
                瞬速・同等になった…。

                現行 10.2R サーバーに比べて disk アクセスが 1.5倍ぐらい遅いような
                気がする問題は、使っている disk の回転数が 7200vs5400 と違うので
                そのせいだけっぽい。

                # smbd死亡問題が片付けばシステム側は一息つくんだが…
                # あと 作業メモ.txtが 手元win／現サーバー／評価win
                # ／14.0Rマシンに、さらに あちこちの dir に
                # 散らかっちゃてるのが地味に結構問題

              • ＜smbd死亡問題＞
                なんか smbd には、vfs objects = cap の時に
                (タイミングによって) dir 読み出しに失敗して
                死亡するバグが samba3 の頃から潜在的にある、
                ような感触。
                    (現サーバーの samba36も、8年間で 75回死んでた)
                ただ Explorer でのファイルコピーでは、src/dst
                どっち方向でも Explorer が きっちりリトライするので
                顕在化しない(ファイルロストしない)、
                ような感触。
                ただ Explorer での「プロパティ」表示では (なぜか)
                リトライが入ってなくて、失敗した分が算入されず
                総ファイル数・総容量が目減りして報告される、
                ような感触。 (これちょっと心当たりある)

                14.0R で発生頻度がうんと上がったところを
                リトライなんてしない UnxUtils diff.exe が
                顕在化してくれてるよう。

              • ＜smbd死亡問題＞
                （上で「dir 読み出しに失敗して」と書いたけど、正確には
                　「dir 読み出し処理でトチ狂って」です、disk から読めない
                　わけではないはずなので）
                で、
                cmd.exe から xcopy.exe でのコピー(sambaから読み出し)では
                エラー中断するケースとリトライして満了するケースがあった。
                diff.exe でも「なんかヘン」と「そんなファイルないよ」と
                エラーが 2種類あったので それで対応が違うものと思われ。

                ここまで unix charset / dos charset = cp932 でやってたので、
                ascii にして vfs objects = cap ありなしの比較をしてみたところ、
                xxx charset = ascii でも vfs objects = cap ありだと死亡する。

                ディレクトリスキャンのような(ファイルの中身にアクセス
                しないので)dir読み出し要求が高速に繰り返されるケースに
                特に弱い、ような感触。
                　（コピー開始直後の「準備しています」ではよく死ぬけど
                　　コピー（読み出し）が始まると死なないとか）
                また面白いのは、explorer で問題ディスク上をマウスポインタで
                hover させるだけで死ぬこと。
                （たぶんヒント表示のためディレクトリスキャンするからと思われ）

              • ＜smbd死亡問題＞
                とりあえずProblem Report [freebsd.org]書いたけれど誰も構ってくれなさそうな感じ。
                portsで自分用smbd作ってdebug-printfで追いかけてみてるけど…まあわからんわからん。
                （条件と被害は限られるみたいだしバグ入り10.2Rを8年使ってきたのだから目を瞑るか…）

              • ＜smbd死亡問題＞
                なんとか回避策に たどり着いた [freebsd.org]けど…
                　（山手線を東京から秋葉原まで時計回りで行った気分）

                # cap_readdir() で d_name[256] があるのに無視して newnamelen
                # まるまる余計にメモリ確保したり d_name[] に 2回 memcpy()したり
                # d_namlen は古い名前のままだったり、capdecode() は ':' があると
                # 問答無用でポインタ+=3してたり CAP 周り結構粗いヨ…

              • ＜smbd死亡問題＞
                とりあえず反映される方向に行った [freebsd.org]みたい…。(i386限定で)

                # pnmscale がもう廃止されてて、ソースから作っても
                # 同じ画像バイナリにならないのが今の hottest topic!
                # -O2 有り無しで浮動少数加減算結果が変わるってなんかヘンだよね？

                  - * - * -

                さて、そんな戦う(時もある)アラ還ロートルな私も実はここしばらく
                Free でして、どなたか仕事をさせてくれる人は居ませんか？
                　（ワケ有りアリアリ かつ 注文も多いですけど）
                to山ＫＥＮ富yam市内に居ます、通いを希望だけど車ありません、
                最寄り駅は桜橋。連絡先は私の"ホームページ [aid.her.jp]"の一番下に、
                私の素性も そこで感じ取ってもらえると助かります…。

              • 14.0R amd64 を試してみてるけど watchdog timeout も一切無く
                smbd もなぁ～んの問題もなく動きますねぇ…。
                　(そういう問題だったのか… orz)

                cc -m32 で 32bitソースもそのまま compile できて
                (32bitバイナリにはなるけど そのまま)動くし
                こりゃ考え直すべきなのかなぁ…。

              • ＜smbd死亡問題＞
                読み出し側で segmentation fault してるのだろうとの見解が…。
                struct dirent の d_name[]は 型としては最大255文字の領域を持つ/持てるが、
                実使用においては名前の文字分しか確保されないため、
                memcpy() でコピー長を無暗に sizeof(struct dirent)すると
                readdir()が確保した以上の領域を読み出す場合があると…。
                というところで Samba Team に報告されました [samba.org]。

                ＜pnmscale画像バイナリ違い問題＞
                -O2 の pnmscale を objdump してアセンブラコードを眺め中…。
                今 "intel表記とatt表記でsrc/dst記述順が逆になるのね" な所。

              • ＜pnmscale画像バイナリ違い問題＞
                コンパイラが最適化の過程で float指定の変数を勝手に double扱い
                している（しかも関数を展開した結果 関数をまたいでまで）ことがわかり、
                コンパイラの扱いに合わせて float→double を明示的に指定して様子見中。
                今たたき台の画像で画素値 1違いが2000ドット（180万ドット中）ほど残ってる状態…。
                （最適化ありで有効数字勝手に増やしていいのか？ は…）

                  - * - * -

                というところで、スラド閉じるそうで、みなさんお元気で～。

      • Re: (スコア:0)

        by Anonymous Coward
        「格闘」頑張ってください！ あとVim遣いを目指したらいいとのアドバイスありがとうございます。

      • Re: (スコア:0)

        by Anonymous Coward

        イマドキ vim なんてサーバの上で config を直接いじるときに使わざるを得ないもの。じゃないですかねぇ。
        VSCode が便利に使えるし。インフラエンジニアとしてだったら覚えててもいいかなという程度では。
        VSCodeは vim キーバインドにして使っているオジサンです。

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall