私はこのサーバーでXOOPSを使ったコミュニティーのWEBをやっていますが、ある時、気がつくと、予定を新規登録しても、メンバーにメールが行かない事態になっておりました（原因は不明。サーバーの引越しなどをやったせい？）
色々調べていくと、本来はカレンダーのリスト表示や各予定の詳細表示の時、表示される筈のイベントの選択画面が表示されていませんでした。
mysqlの何処かにこの設定があると見当を付け、色々なテーブルを調べると、（mysqlのやり方は下の方の続き...をクリックして下さい）xoops_config（最初のxoopsは初期設定の時の接頭語）というテーブルがあり、ここに色々な設定を保存しているようです。調べるとconf_modidが１５（私の場合はpicalのmodidは１５になっていた）conf_nameがnotification_enabled、conf_valueが１になっているデータを発見しました。他のモジュールでイベントを表示する分は３になっていましたので、此所を強引に３にしたら、無事リスト表示などにイベントが表示され,ここにチェック・マークを付けて、今すぐ更新をクリックした後は、メールが来るようになり、問題が解決しました。
本来なら、なんでこのデーターが１なったのか、原因を調べなければいけないし、３にするためのプログラムが何処かにあると思うのですが、私の能力では分かりませんでした。
memo:メールの送信判断はxoops_xoopsnotificationsというテーブル。
モジュールIDを調べるにはxoops_modules。

この所、日射が強くなって来たのが原因なのか、前より低い電圧、２６．４Ｖでも直列にした方が（並列で2個合計２．６Ａ、直列で５Ａ）断然良い。春は２７Ｖ位だった。
又、梅雨も終って、曇や雨の日が少なくなって、この所、補充電が入っていない。つまり太陽電池からの充電のみで、サーバーが動いている。何日位補充電が入っていないかは、ロガーを見ればいいのですが、今は記録途中なので、記録中のデーターは見れない仕様なので、後日報告します。これは６月２０から７月１日までのデーターです。この頃はまだ梅雨で、晴れてる日があまり無かったのですが、補充電は殆ど入っていません。途中で強制充電をしているのは電池の比重をあげる為です。補充電が入らなくなったのは、サーバーのディスクをSSDにし、消費電流が減少した為です。このサーバーは仮想化（XEN)を使って、全部で４台のコンピューターが入っている設定をしていますが、今、付いているハードディスクは３台のwindow機とサーバーのバックアップ用の５００GBの2.5インチ７２００回転の1台だけです。
又、このサーバーの他に、電池から電源を取っているのは、常時電源ONでなければならない光終端装置、NTTからレンタルのルーター（このルーターはレンタルのみ、私みたいに同じ者を長く使っている者には非常に不経済。NTTさん何とかして） とスイッチング・ハブ。それでも消費電流は４A弱

１日立って、気を落ち着かせて、原因を考える。
壊れたディスクと新しいディスクはコンピューターから見るとまったく同じ物。
ファイルの構造も同じだし、ファイルの所有者も同じにしたし、各ファイルの読み書きの権限も全く同じにした。レグザの詳しいWEBの管理人の竹田さんから教えてもらった事もした（隠しファイルを消去することと、UUIDを同じにする事）。
それでも再生出来ない！！やっぱり１日経っても分からない。何か見落としがあるのだろう。
DVDもコンピュータからのコピーだと見れないからそんな所か?？でも、少なくとも竹田さんはコンピュータからコピーをして見れるようになったのだ。
レグザから見ると、どうも他のレグザで記録した物の様な振舞に見えるので、記憶には無いが、隠しフォルダーの中身が古いディスクと同じになっていない(ファイル構造でなくファイルの中身）のかも知れない。
コンピュタをいじっていると、よく”同じ事をやっても同じにならない”という現象に出会います。私見ですが、これは人間様が同じ事をしたと思っているだけで、コンピュタ側からしてみると同じ事をしていないんだと思います。他に設定があり、それが違っていたり、やったつもりでやっていなかったり色々です。たまに熱のせいで挙動が変化する事はありますが、今回は当てはまらないと思います。
参照: 後日別のXFSのディスクが壊れ、その顛末を書いております。"LinkStationのディスクが壊れた"を参照してください。raid0(半角)で検索できます。2013-05-10追記

昨日やっとコピーが終った。最終的に６月分の殆どでエラーが出ていたが、正常終了した物も半分くらいあると思う(６月以前が殆ど）。エラーが出たので、大きい .dtvが極端に小さくなっているのものがたくさんあり、この為に２１日間？もかからず終った。もちろん残りの .dtv.meta と .dtv.rat もコピーをして置いた。http://www.4682.infoの管理人の竹田さんに教えてもらった事をやる。（このWEBはレグザを使っている人には貴重な情報源）
このディスクのルートにある　.から始まる3つのファイルを消し（　.で始まるディレクトリーも有るがそれは消去しない）、umountしてから
# xfs_logprint /dev/sdd1
とし、壊れたディスクのUUIDを調べておき、それを
# xfs_admin -U '調べたUUID' /dev/sde1
として、新しいディスクに書き込んでおいた。
自宅にレグザが無いのでubunntuの起動CDを持って友人宅へ。
http://www.4682.info/copyによるとUUIDを壊れた分にすると、レグザは壊れたUSBディスクとして認識するとあるが、私の場合は、USB3（USB2が壊れたディスク）として認識した。(新しいディスクは友人にレグザに付け、登録をしてもらっていた。）おかしなー。でも録画番組のリストはエラーが出ていた分も含め全部見えているっぽい。でも全てが”再生できない”となって一切再生が出来ない。
考えられるのは、xfsdumpをしている時に途中で止まった為、XFSのフォーマットを掛けたので、多分新しいディスクがレグザで登録をしていない状態になっていたのかも知れない。もう一度レグザに登録をしてから、再度コピーをすればいいのかも知れないが、さすがに又、一週間以上のコピーはきつい。
という訳で、再生出来ていない状態。
xfsdumpをしないで、フォーマットもしなければ、多分見れると思う。後日、竹田さんから連絡があったが、フォーマットしても、隠しフォルダーとUUIDを同じにすれば関係ないとのこと。とすると原因は？？？謎は深まるばかり。
歯切れが悪いが、取り合えず今回は此所まで。
少し時間をおいて再挑戦してみるつもり。

という訳でコピーをしていたら、昨日の夜からやたら入・出力エラーが出るようになった。
それとコピーの速度がものすごく遅くなった。１時間で約１GB位これだと残り５００GBに５００時間（約21日間！！！ ）
もう３日以上ディスクが動きっぱなしなので、やばいのかと思い（そんなに熱くはなっていない。触っても少し熱いと感じる位）少し休める事にした。私は節電のため、作業場はまだエアコンを点けないで、がんばっていたのですが、約５時間くらい後、エアコンをONにし、ディスクに直接扇風機の風が当たるようにし（以後、ディスクは全然冷たい）再度作業開始、前回と同じ nobarrier オプションも点けテストするがやはり１GBから速くならない
レグザのシステムは3fileで１番組の記録をしているが（ファイルの最後が .dtv .dtv.meta .dtv.rat）この .dtv(いちばん大きいにで本体と思われる）でエラーが出ているので
# cp -pu /test1/*.dtv /test2 → カーレントディレクトリはroot
をやって様子を見ているが、やはりエラーが出ている。とにかく終るまでやって見よう。
ちなみにエラーは全部では無いが６月分に集中している。
ファイル名に日付が数字で入っているので、録画をすると日付け順にファイルが作られる筈。すると新しい記録ほどファイルシステムの後ろの方になる筈。これが理由で記録の後ろがいっぱい壊れているのか、何日間もディスクが動きっぱなしになっていたから、故障が進んだのかは不明です。ただ今でも壊れたディスクのファイル名は判る。
又、壊れたのは当然最後の記録で、その分は .dtv のサイズがゼロで、.dtv.meta が無かった。

BUFFALOのUSBの２テラのディスクで、linuxにつなげると認識しない。
/dev以下を見ると、それまで無かった、sddとsdd1があるので、これがこのデスクの筈。
# mount /dev/sdd1 /test1
でマウントしてみるが、ファイルタイプを指定しろ、と怒られる。
# fdisk /dev/sdd
としてパーティションを見ると、EFI GPTになっている。BIOSでなくEFI??
レグザ　ディスクでググると色々ヒットし、調べるとレグザはファイルシステムとしてXFSを使っているという。centosはXFSをdefaultではサポートしていないので
yum から xmod-xfs,xfsprogs,xfsdumpをインストールし再起動
http://www.4682.info/repairと言うWEBを見つけ、その様にやるが
# xfs_repair -Lv /dev/sdd1
の所で、
Phase 1 - find and verify superblock...
superblock read failed, offset 406337564672, size 2048, ag 13, rval -1
となり復旧出来ない。
もうー、頭に来たぞ！意地でも直してやると憤ったのですが....
色々調べると、mountオプションに norecovery があるのを発見、
# mount -t xfs /dev/sdd1 /test1 -o ro,norecovery
でマウントするとエラーが出ない。
# ls -la
とするとたくさんのファイルが見えた。
友人が持ってきた新しいUSBディスクを付ける。これは問題無く自動でマウントされたが、私は自動マウントだとマウントの指定が長くなるので、アンマウントし、
# mount /dev/sde1 /test2
とし、/test2にマウントした。
又、色々ググって
http://docs.cray.com/books/S-2377-22/html-S-2377-22/fixed6bhdyq9i26.htmlというWEBを見つけ、早速試す。このWEBの7.7.3によるとxfs_dumpとxfs_restoreを使えとあるので、
# xfsdump -J - /test1 | xfsrestore -J -p 60 - /test2　→ -p 60は６０秒毎に経過を表示するオプション。
とコマンドを打ったが、
４時間ぐらい立っても　1.8%　recoverから進まない。別ウィンドウから
# ls -la　/test2
と/test2 の中を見ても全然コピーしている様子は無いし、ファイル数も増えていないので　ctrl+c で強制リセット
うーむ、困った。WEBにはパス１でエラーが出たら、バックアップからコピーをしろと書いてある。普通レグザで記録する人はバックアップなんかしていないと思う。私の場合はパス１でエラーが出ている。
少なくとも上記の方法でマウントしファイルが見えているので、方法がある筈。
linuxに標準のext3というファイルシステムだと、バックアップされているsuperblockを使って復旧する方法があるのですが、どう調べてもXFSでバックアップされているsuperblockの復修方法が判らない。
どうも　xfs_repair　がそうだと思うのですが、オプションの中にそれらしき物は試した -Lv しかありそうに無い。
ダメ元で
# cd /test1 → カレントディレクトリーを移し、
# cp -pr ./ /test2　-pr は パーミッションやタイムスタンプを保持したままコピーし、ディレクトリを再帰的にコピーする（つまり、サブディレクトリーがあったらその下もコピーする）
とコピーが始まった。但しものすごく遅い、１時間に５GB弱位しかコピーしていない。それでも出来ないよりましと、コピーを続けるが、１日たっても１１５GB　遅すぎる。そう言えばコマンドからでなくファイルブラウザから（windowでいう所のエクスプローラ−−インターネット・エクスプローラじゃないよ−−）/test2を見た時ものすごく時間がかかったのだ。5分間位ディスクのアクセスランプが点滅した後、点滅が止まるとやっとファイル達が見えた！！
多分superblockが壊れているのが原因で時間がかかると思う。仕方ないか
コピーをしながらググっていると mount に nobarrier と言うオプションがあるのを発見、マニュアルには無いぞー（man mount)
ダメ元で試して見よう。
コピーを強制終了（コピーが動いているウィンドウの上にマウスを持っていきで ctrl+c)
# cd → カレントディレクトリがtest1だとアンマウントできないので
# umount /test1
# umount /test2
強制終了したのでコピーされる側(新しいディスク)はおかしくなっているので
# xfs_repair -Lv /dev/sde1
（この時、USBでは速度が遅くなることも考え両方のディスクを裸にし、SATAで直接コンピュータに接続した。もちろん電源を落とし、接続後起動＊＊ここでBUFFALOに一言：ハードディスクのケースの下側の爪が弱すぎる。型番はケースにHD-CL2.0TU2/NとHD−CB2.0TU2/WHとある。2個の爪2台とも壊れた。プラリペアで修理）
再度nobarrierを使ってマウントする
# mount -t xfs /dev/sdd1 /test1 -o ro,norecovery,nobarrier
# mount /dev/sde1 /test2 -o nobarrier
コピー途中にエラーが出ていたので、そのファイル2個（更新日時がコピーした日になっている筈）と最後にコピーされたファイル（終っていない）を消去する。
コピーする
# cd /test1
# cp -p -u * /test2 → -u は同じか新しい物があるとコピーをしない（つまり以前のコピーの続きからコピーをする）-rが無いのはサブディレクトリーはコピーが終っていたから。
するとコピーの速度は１時間で１０GB強位になった。しめしめ。まだ遅いが仕方ない。友人のディスクは半分くらい使っていたのであと３日位かる。
現在はコピーの途中なので、コピーが終わり、テスト後、報告します。

比重を測ると電圧は２８Vもあるのに、１．１８（比重計の赤い所）しか無い 。 　しょうがないので、過充電を覚悟で、強制的に補充電を入れる。１時間ごとに比重計でチェックすると、１．２６（緑の所）になった時には電池電圧は３１．７５V（約４A弱の負荷を付けたまま）になっていた。この時の充電電流は１０．２A位ですが、負荷をつけたままですので充電には８A強しか廻っていません。
うーむ、やっぱり過充電防止電圧を上げよう。東側の２枚の太陽電池を直列から並列に戻す電圧を３１．６V。西側の２枚づつを３１．６５V、３１．７Vにそれぞれ設定しなおして、様子を見てみます。
その後は以前に比べて電池が持つようになった。やはり充電が足りなかったみたい。　5/6から5/17のデーターはここ。5/28から6/8のデーターはここ。6/8から6/18のデーターはここ、この時サーバーのハードを変更しました。マザーボード、ＣＰＵ、メモリーなどは変更ありませんがハードディスク2.5インチ3台プラスＳＳＤをハードディスク2.5インチ1台とＳＳＤ二つに変更しましたので一瞬電流が増加し（2台動いていた）その後の平均の消費電流が減少しています。変更後に消費電流の変更幅が多い所では、3台あるWindow機のバックアップを新しいサーバーにしていた為ですので、今後はもっと消費電流は下がります。この後の強制充電の電圧を見るとわかりますが３１．５Ｖ位から充電をしても電圧の上昇はありませんが、比重はこの時に上がっております。この結果から過充電防止は電圧でなく比重などで判断をしたほうがいいのですが、比重を電気的信号に変える方法が安価に出来そうにありません。こうであれば過充電防止はつけなくてもいいのかも？。単位はA又はVで充電電流に補充電の電流は入っていません。

仮想環境で作ったメールサーバをpostfix,dovecot,qmail,vpopmailからシンプルにするためにpostfix,dovecotのみの環境に変更するためdomUを新しく作り、ローカルのIPアドレスを別のIPにしたらローカルのコンピュータからメールの送受信が出来なくなった。もちろんこの時、新しいサーバーの送受信テストはしっかりやり、IMAPを使っているので旧サーバーからメールを新サーバーにコピーした。サーバー名等は変更しなかった。メールソフトのSMTPやIMAP(POP)サーバーはサーバー名とドメインで設定をしてあり、私が使っているFLETSからレンタルしているルーターは（RT-S300SE)はローカルから出てそのままローカルに戻ってくるパケットはサポートしていない様で（メールソフトから出てDNSで自分のIPが指定され、自分のルーターのWANポートに帰ってくる）エラーが出た。それ故/etc/hostsにメールサーバーのIPが指定されていたが、これが原因。/etc/hostsを新しいメールサーバーのIPに変えたらOK。考えてみれば当たり前のことだが、ついつい忘れてしまうのでメモ。
こんなことなら、ローカルのコンピュータの全てのhostsファイルを書き換えなければならないので、テスト後は古いIPにした方がよかった。

ロガーでデータを取りました。ここをクリックして下さい（PDFファイルで２５９KBあります。）メモリはV(ボルト）またはA(アンペア)です。太陽電池からの電流は6台あるすべての合計で補充電の電流は入っていません。
24V弱で急激に電圧が上がっている所でSW電源が入り、充電し、２８V強でOFFになり電池電圧が急激に落ちているのがわかります。5月6日から17日までに3回補充電が働いています。又、３０Vを超えたところで急激に上がったり下がったりしているのは、自動で太陽電池を直列にしたり並列に戻したりしている所です。夜中に電流が増えているのはこのサーバーはXENで仮想化し、WEB・メールサーバーやファイル・バックアップサーバーを動かしていますが、そのバックアップサーバーがWEB・メールサーバーなどをバックアップしているので使用電流が増えています。

今まで東側の太陽電池は手動のみで直列にしていましたが、こちらも自動で切り替えるようにしました。直列にする電圧は西側と同じ28.3Vにし、並列に戻す電圧（過充電防止の為）を30.8Vにしました。制御回路図はここをクリックして下さい。
直列にする電圧は天気が良ければ２７．２V位でも並列より良くなりますが、雲が多いと、悪くなるので、ここに設定するとリレーがチャタリングを起こしますので、２８．３Vにしています。
そもそも太陽電池の公称最大出力動作電圧が30V位あればこんな苦労はしないのに
現在の制御基盤


























SW電源の100V整流用のブリッジダイオードが触れないくらい熱くなるのでアルミ板を付け放熱した。又その際突入電流防止のためにある抵抗と半導体をはずした。ゼロクロスSWで電源が入るので突入電流は考慮しなくて良い。