ブログ

セッションテーブルのエラーでログインができなくなる

2025-04-24T23:59:36+09:00

　サイトは動いているけど，ログインができなくなった．こんなメッセージが表示される．

　これｈXOOPSCubeのセキュリティプラグインProtectorに関するもの．

　昨晩大量のSQLインジェクションなどを受けたのでクロスサイトスクリプティングも受けていただろう．．．DDoSには少し弱いかもしれない．

　セッションデーブルを確認．

mysql> select count from XOOPSDB__session;🆑
ERROR 145 (HY000): Table './XOOPSDB/XOOPSDB__session' is marked as crashed and should be repaired
mysql>

　やはりユーザセッションを管理するテーブルが壊れていた模様．
　修復する．

mysql> REPAIR TABLE XOOPSDB__session;🆑
+------------------------+--------+----------+----------+
| Table                  | Op     | Msg_type | Msg_text |
+------------------------+--------+----------+----------+
| xoops.xoopsdb__session | repair | status   | OK       |
+------------------------+--------+----------+----------+
1 row in set (0.09 sec)

mysql>

　これでログインができるようになった．

（３号機）ヤフオクで３号機を調達，そして交換へ

2025-02-12T19:11:31+09:00

　2009年10に２台買った整備調整品のMacBook late 2008ですが，その時DVDドライブに初期不良のあったのが２号機．その後，カミさんのメインPCとしたけど使われず，寝ていた期間が長かったけど，気がついたら起動しなくなってました．
　そして代替え機として2024年9月にヤフオクで予備機の代替機を購入．

落札金額：4,400円
送料：910円
支払金額：5,310円

　商品説明にはこう買いてあった．

引用：

商品は譲渡頂いたお品で本体、電源コード、キーボード保護カバー他画像にある物だけになり、本体は小さなスリキズ等は確認できるものの、表面、裏面、タッチパッドには保護フィルムが付いたままで、私感ですが極上の美品中古の部類ではないかと思います。
しかしながら、バッテリーが経年劣化で使えない、本体に認識されていない商品になります。（画像9参照）
電源コードは汚れや何かしらの色の付着がございます。

通電と一部動作確認済（ネット通信、CD・DVDの再生読み込み）。画像7、8参照
ネット通信はOSやブラウザが古いので展開はできませんでした。
タッチパッドには保護フィルムが付いたままですので動作確認時の反応は悪く、剥がしておりませんので本来の状態は確認できていない現状となります。

　元箱も完備で本体は綺麗．しかしタッチパッドがクリックできない．この機種，裏返してバッテリを外すとタッチパッドのクリックをネジで調整する機能があるけど，それをしても調整できない．どうも持病として不具合があった模様．

　早速２号機からメモリとSSDを移植して起動してよくみたら，MacBook 2008 lateの中の上位CPU版のIntel Core 2 Duo 2.4GHz版でした．

　意図せず20%の性能アップ．

　そこまで準備して放置していたのだけど，最近，１号機が不定期にダウンする．稼働中も冷却ファンからの異音が．．．

　初期不良の修理から戻ってきたのが2009年10月17日なので，そこから計算したらこんな感じでした．

　ほぼ15年4ヶ月．ハードもソフトも，色々とカスタマイズしたので新しいサーバへの移行はとても難しい．．．

　そして新たな予備機の準備が必要．．．

追記2025/02/13
　１号機から３号機に交換して，CPUスペックが上昇したけど，それによりCPU温度が下がった事が確認できた．

　CPU温度が下がっているけど，その他のパームレストやバッテリ温度は変化がない感じ．CPU性能がアップしたことで改善した事が確認できた．

（１号機）　mysqldump: Got error: 145: Table './WEBDB/WEBDB__session' is marked as crashed and should be repaired when using LOCK TABLES

2025-02-04T13:37:32+09:00

　crontabで定期実行しているMySQLのバックアップが失敗している．失敗というかダンプファイルが肥大化しでディスクフルになった．．．
　手動で実行してみたら，こんなエラーだった．

sh-3.2# DBbackup.sh
mysqldump: Got error: 145: Table './WEBDB/WEBDB__session' is marked as crashed and should be repaired when using LOCK TABLES
sh-3.2#

　これはWebアクセスのセッションテーブルが壊れている模様．DDoS攻撃を受けた結果，被害が出たと推察．

　まずは壊れたテーブルを確認．

mysql> check table WEBDB__session;🆑
+------------------------+-------+----------+-------------------------------------------------------------------------------------------+
| Table                  | Op    | Msg_type | Msg_text                                                                                  |
+------------------------+-------+----------+-------------------------------------------------------------------------------------------+
| WEBDB.WEBDB__session | check | warning  | Table is marked as crashed                                                                |
| WEBDB.WEBDB__session | check | warning  | 13 clients are using or haven't closed the table properly                                 |
| WEBDB.WEBDB__session | check | warning  | Size of indexfile is: 913408      Should be: 659456                                       |
| WEBDB.WEBDB__session | check | error    | Invalid key block position: 270216091030151533  key block size: 1024  file_length: 659456 |
| WEBDB.WEBDB__session | check | error    | key delete-link-chain corrupted                                                           |
| WEBDB.WEBDB__session | check | error    | Corrupt                                                                                   |
+------------------------+-------+----------+-------------------------------------------------------------------------------------------+
6 rows in set (2.97 sec)

mysql>

haven't closed the table properly（適切に閉じてない）．delete-link-chainが壊れているとのこと．

　delete-link-chainはMyISAMで，削除されたレコードを管理する仕組みで，これが壊れているということになる．

　リペアを実行して再度チェックして修復できたことを確認．

mysql> repair table WEBDB__session;🆑
+------------------------+--------+----------+------------------------------------------+
| Table                  | Op     | Msg_type | Msg_text                                 |
+------------------------+--------+----------+------------------------------------------+
| WEBDB.WEBDB__session | repair | warning  | Number of rows changed from 1800 to 1797 |
| WEBDB.WEBDB__session | repair | status   | OK                                       |
+------------------------+--------+----------+------------------------------------------+
2 rows in set (0.29 sec)

mysql>

mysql> check table WEBDB__session;🆑
+------------------------+-------+----------+----------+
| Table                  | Op    | Msg_type | Msg_text |
+------------------------+-------+----------+----------+
| WEBDB.WEBDB__session | check | status   | OK       |
+------------------------+-------+----------+----------+
1 row in set (0.01 sec)

mysql>

（１号機）　Apacheの定期再起動はパフォーマンス改善に効果がある

2023-11-18T09:28:21+09:00

　某サーバのuptimeを確認．

juno:$ uptime🆑
 2:59  up 665 days,  9:28, 2 users, load averages: 0.18 0.30 0.31
juno:$

　以前542日と言うのがあったけど，それを更新していた模様．
　665日前と言うと，2022年1月22日か．体温計を買ったりしていたようで，どうして再起動したのかは覚えてないなぁ．．．

　ふと気づいたのだけど．
　先週，ログ出力タイミングを変更するために，Apache httpdを再起動(apachectrl stop;apachectrl start)したんだけど，そうするとCPU timeが減りました．

　そして，もっと長い目で見ると長期間動作したまま運用していると，httpdのCPUタイムがどんどん増えていることが確認できました．

　これは興味深い．

　ちなみに，Apache 1.3脳なのでMPMはpreforkで設定してあります．

juno$ /opt/local/apache2/bin/apachectl -V|grep MPM🆑
Server MPM:     Prefork
 -D APACHE_MPM_DIR="server/mpm/prefork"
juno$

　MPMの詳細はこれ．

juno$ cat /opt/local/apache2/conf/extra/httpd-mpm.conf🆑
# worker MPM

    StartServers          2
    MaxClients          200
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   5000

　つまり5000リクエスト処理したらプロセスが死滅するようにしているので，メモリリークとかがあってもサーバOSダウンにならないよう制御しているのですが，親プロセスか何かが長期間運用しているとゴミ？が溜まって動作が重くなって非効率化し，CPUタイムをたくさん消費する状態になっていると言うことのよう．
　それを解消するには，OSの再起動までいかなくても，Apache httpdを再起動で効果が出る模様．

　実際，その某サーバのWebページにアクセスすると，レスポンスがとても速い．やっぱり定期再起動を入れておくのが良いのかな．

　そして今回は，DirectoryServiceの再起動を兼ねてOS再起動を実施したのでまた色々とリセットされたのだけど，Apache httpdだけ定期再起動にしてみよう．

（２号機）　バッテリの交換修理　その５　メールサーバ引退，バッテリ消耗

2022-04-12T10:54:46+09:00

　1年，メールサーバ専用機として稼働してもらったけれど，その地位はmac mini 2010に譲って引退．
　ネットワークから外し，しばらく放置していたら，なんだか熱い．電源を入れてみようと思ったら電源が入らない！
　流石に購入して13年くらいになるので壊れたかな？と思ったら，バッテリ不良でした．

　容量が194mAhだなんて．新しくバッテリを買いますかね．

　１号機も今年の初めに交換していますね．前回この２号機のバッテリを変えたのはいつだったか．．．

　ちなみに，うちの行政だと，パソコンのバッテリはリチウムイオンなのでモバイルバッテリと同じ捨て方で回収してくれました．

ブログ

セッションテーブルのエラーでログインができなくなる

（３号機）ヤフオクで３号機を調達，そして交換へ

（１号機） mysqldump: Got error: 145: Table './WEBDB/WEBDB__session' is marked as crashed and should be repaired when using LOCK TABLES

（１号機） Apacheの定期再起動はパフォーマンス改善に効果がある

（２号機） バッテリの交換修理 その５ メールサーバ引退，バッテリ消耗

（１号機）　mysqldump: Got error: 145: Table './WEBDB/WEBDB__session' is marked as crashed and should be repaired when using LOCK TABLES

（１号機）　Apacheの定期再起動はパフォーマンス改善に効果がある

（２号機）　バッテリの交換修理　その５　メールサーバ引退，バッテリ消耗