/ usr / sbin / mysqldが削除され、iノードが異なる別のmysqldに置き換えられました
これは、RHELで実行されている3つのmysqlサーバーで発生しました。開いているファイルと削除されたファイルを確認しているときに、使用中のmysqldが削除され（lsofに表示されるように）、iノードが異なる同様のmysqld（/ usr/sbin/mysqld内）に置き換えられていることがわかりました。両方のファイル（削除済みと現在）のサイズとブロックは同じです。新しいmysqld（使用されていません）は、削除されたものと同じバージョンのようです。私はこれを引き起こした可能性があるものを理解しようとしています（システム上で実行されているcronジョブはありません）。システムログ、データベースログ、yumログを確認しましたが、関連するものは何も見つかりませんでした。どんな入力でも大歓迎です。
ありがとう！
一見すると、これは 非常に 疑わしいですが、以下の情報に基づいて、直感に反するものの、非常に論理的で危険ではない説明があるかもしれません。
好奇心から、いくつかのLinuxマシンで重要だが削除されたファイルを探したところ、次のような興味深いものが見つかりました...
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 30851 root txt REG 202,1 959120 142485 /bin/bash
bash 31501 root txt REG 202,1 955024 131092 /bin/bash (deleted)
うわぁ。本当に？
これらのシステムはaptvs yumシステムですが、原理は同じです... Windowsの世界では考えられませんが、Linux（またはUnix afaik）の世界では、「開いている」ファイルを上書きすることはまったく賢明であり、それほど予期しないことではありません。別のプロセスによって。ファイルに割り当てられたスペースは、ファイルを保持しているすべてのプロセスが開いているとすぐに解放されます...ファイルを閉じます。
私の場合、ログは、最後の再起動以降にアップグレードされたパッケージの1つに「bash」が含まれていることを確認しますが、実行中のbashのコピーの一部は、実際には更新前に実行されていた古いbashのままです。
しかし...あなたのバイナリは私のものが異なる同じサイズなので、これはそれが完全なアップグレードではなかったことを示唆しているように思われます。これにより、mysqldを含むパッケージのアップグレードである可能性があるが、mysqld自体は変更されなかったため、ファイルがそれ自体の同一のコピーで上書きされたのではないかと推測しました。しかし、それは憶測のようです。
私は憶測が好きではないので、掘り続けました。私は最近Ubuntuを使用していますが、まだ古いRed Hatマシンがいくつかあるので、/etc/cron.*のディレクトリを調べて、prelinkに出くわしました。
システムで実行されているcronジョブはないとおっしゃっていましたが、それについてはよろしいですか？/etc/cronの「ファクトリ」デフォルトのcronジョブでさえありませんか？
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
実際にnocronジョブが実行されている場合、もちろん、この投稿の残りの部分は意味がありませんが、文字通り持っていることは私には非常に珍しいようですnoRedHatマシンでのcronジョブ。
/var/log/prelink/prelink.logのタイムスタンプを見てください。問題の時間枠に一致する場合は、容疑者がいます。
私はDBAよりもずっと長い間Linuxのシステム管理者でしたが、どういうわけかこれに遭遇したのはこれが初めてです。率直に言って、最初に読んだとき、一晩のプロセスが実際に突っついていることに緊張しました。実行可能ファイル内のビットで、しかし私はそれがそうであるように思われるほど問題ではないと思います。
パッケージマネージャーを使用してMySQLをインストールしたことがないため（何かが私以外に触れるにはあまりにも重要だと思います）、おそらくそれは私の注意を引くことはありませんでした。公式のバイナリディストリビューションをインストールするための「標準」パスは/ usr/local/mysql [/ bin]であり、これはプリリンクが接触するパスにはありません。
Prelinkは、プログラムの実行を最適化し、実行可能ファイルと共有ライブラリ内のアドレスをシステムごとにいくらかランダムにすることで、バッファオーバーランに基づくエクスプロイトに対するある程度の耐性を提供します。 可能性があります各マシンにインストールされているソフトウェアの組み合わせに応じて、各マシンのmysqldバイナリの現在のコピーは同じサイズですがそれらが同じバージョンであっても、実際には互いに同じmd5sumまたはsha1sumチェックサムを持っていません。今日まで、それはまったく意味がありませんでした...しかし、私がプレリンクで見つけたものを考えると...この時点で私を驚かせることはありません。
http://people.redhat.com/jakub/prelink/prelink.pdf
これが起こった可能性が非常に高いと思います。サーバーが適切にファイアウォールで保護されており、他に問題がないように思われる場合、侵入者が同じ方法で複数のマシンを意図的かつ正常に侵害した可能性は低いと思われます。
上記が有望な候補であることが判明した場合、実行中のmysqldプロセスをシャットダウンしない限り、削除されたファイルにアクセスしてコピーを作成できることを不思議なことに見つける必要があります。私は、それらを元に戻すことを断固としてお勧めしませんが、興味がある場合は、次の情報が役立つ場合があります。
Lsofおよびcdからシステムの/proc/nnnnnディレクトリにmysqldのプロセスIDを見つけます。nnnnnはプロセスIDです。
このディレクトリ内には、exeと呼ばれる壊れたシンボリックリンクのように見えるものがあります。実際には、削除されたファイルを非常に現実的な方法で参照しているため、これは見た目とは異なります。
上から削除した「bash」のコピーの1つを使用して、残りの部分を説明します。プロセスIDは31501でした。
root@Host:/# cd /proc/31501
root@Host:/proc/31501# ls -l exe
lrwxrwxrwx 1 root root 0 May 1 06:41 exe -> /bin/bash (deleted)
まだ開いているという理由だけで、実際にcp exe /some/new/placeして、この削除されたファイルを回収することができます。繰り返しになりますが、このコピーの使用を開始することはお勧めしませんが、バイトごとの詳細な分析を行う場合は、これが削除されたディスク上にあるコピーです。
より粗い例として、チェックサムを実行できます。繰り返しますが、この例は私のシステムのもので、プロセス31501である「bash」が削除されています。
root@Host:/proc/31501# md5sum exe
748c6ee926dd3cf55bcfb60ce928d367 exe
当然のことながら、これは私のシステムの「bash」のライブコピーと同じチェックサムではありません。
root@Host:/proc/31501# md5sum /bin/bash
3cac23b8442e3971f1d10660cc779b9f /bin/bash
しかし、偶然にも、上記のマシンほど最近アップグレードされていない別のマシンがあります。このbashのコピーは、私のマシンで削除されたコピーとまったく同じサイズであり、チェックサムも同じです。
user@older:~$ ls -l /bin/bash
-rwxr-xr-x 1 root root 955024 Apr 3 2012 /bin/bash
user@older:~$ md5sum /bin/bash
748c6ee926dd3cf55bcfb60ce928d367 /bin/bash
あなたもできます...しかし、あなたは本当に本当にすべきではありません...実際にrunのプロセスディレクトリ内から「exe」で表されるファイルmysqld（私のものは21691で実行されています）。真剣に、それをしないでください。しかし、興味があれば、これが何をするかです。実行可能ファイルは、ディスク上の名前を使用して、それ自体を./exeとして識別しています...しかし、MySQLは大丈夫です：
/proc/21691# ./exe --version
./exe Ver 5.6.10 for linux-glibc2.5 on x86_64 (MySQL Community Server (GPL))
どのようにそのことについて？
ファイルのサイズが異なる場合、何かが正しくありません。
コマンドラインで実行してください
mysqld --version
両方のmysqldバイナリを使用します。
私の推測では、それらはmysqldの同じバージョンである可能性がありますが、2つの異なる方法でコンパイルされているか、異なる方法でインストールされている可能性があります。おそらく、mysqlのyumインストールがいくつか行われたのでしょう。
MysqldのRPMインストールは、ソースでコンパイルされたmysqldと同じサイズにはなりません。通常、mysqldのソースコンパイルバージョンには、mysqldではなくmysqlのサービス名が付けられます。
それを見つける方法はこれを行うことです：
cd /etc/init.d
ls -l mysq*
mysqlまたはmysqldのいずれかが表示されます。 mysqlが表示されている場合、それはRPMインストールでした。 mysqldが表示されている場合は、ソースでコンパイルされたmysqldが/usr/binにあるか、yumがインストールされたmysqldサービスがワイルドになっている可能性があります。