updatedbを無効にすることはできますか？

26

あるupdatedbすべての必要な？私は決して使用せlocateず、サーバーには数十億のファイルがあり、通常、updatedbを長時間実行し、MySQLや他のソフトウェアに必要なI / Oを消費します。

cronから削除してすべてが機能することを期待できますか？（サーバー上で見られる通常のソフトウェアをすべて意味する：linux、cpanel、mysql、apache、phpなど）。

linux performance io updatedb

— マット
ソース

25

はい、cronで無効にするか、を提供するパッケージを削除できますupdatedb。Red Hatシステムでは、削除する前に何かが必要かどうかを判断する手順を実行します。

まず、プログラムがディスク上のどこにあるかを調べます。
```
$ type updatedb
updatedb is /usr/bin/updatedb
```
次に、パッケージが提供するものを調べますupdatedb。
```
$ rpm -qf /usr/bin/updatedb
mlocate-0.26-3.fc19.x86_64
```

何かが必要かどうかを確認しますmlocate。

$ rpm -q --whatrequires mlocate
no package requires mlocate

何も必要ないので、パッケージを削除できます。
```
$ yum remove mlocate
```

— slm
ソース

1

rpmもあり--whatrecommendsます。Fedoraは過去数年でそれを概念として検討し始めたと思います。（debian / ubuntu側がデフォルトで「推奨」依存関係と「必須」依存関係をインストールするようになった後）。

— sourcejedi

削除した後に削除でき/var/lib/mlocateますか？

— ラムラタングプタ

1

@RamratanGupta -はい

— SLM

13

構成ファイルを/var/www編集することにより、（たとえば）多くのファイルがあるディレクトリのスキャンを無効に/etc/updatedb.confできます。本当に無効にしたい場合は、cronjobを削除してください。

— ブレノザン
ソース

5

パッケージマネージャーを使用して削除します。別のパッケージがそれを使用している場合、依存する必要があるため（パッケージの依存関係）、わかります。

私は、サーバーを持ってNginx、php-fpmそしてmysql、それはせずに美しく動作しますupdatedb。

— アウラロン
ソース

さらには、aptであなたが使用することができaptitude remove、aptitude whyまたはaptitude search '?installed ?recommends(mlocate)'。これらは、必要な依存関係に加えて、推奨される依存関係をすべて表示します。aptはデフォルトで推奨パッケージをインストールするようになったため、必須とは見なされませんが、非常に便利なサブ機能を提供するために信頼される可能性があります。

— sourcejedi

0

私はこれを言って手足に遠くまで行くつもりはありませんが、おそらくあなたの問題を引き起こしているのは更新されていないbです。おそらく、あなたが「好み」に設定していないバックアップアプリケーションか、プロファイル/システムグループ構造のセキュリティ上の問題のいずれか、あなたが望まない何か。

システムのメモリ割り当てがユーザーに対して機能していると思われるもう1つのケースは、「知らないスタック仮想ファイルシステム」のシナリオです。そしてそれは問題の鼻くそです。いわば「仮想の不正論理爆弾」。

ext 4システムのfat32でフォーマットされたUSBドライブが非常に頻繁に発生し、その後、cshシェルがmanログインシェルとして不適切にセットアップされているzfsシステムに転送されます。ディスク上に「読み取り専用USBファイルシステム」問題の仮想再帰を作成し、fat32からvFatにドライブをフォーマット/マウントします。これにより、不良ブロックセクターが作成され、ディレクトリが抽出されます（仮想的に移動）無限ループを引き起こす親ディレクトリレベル！ディレクトリは、物理的に親の階層レベルではありません。cshの原因の構文がこの原因です。*注意：ドライブは、zfs c-shellログインシステムを除くすべてのシステムでのみ読み取り可能です。

updatedbを完全に無効にすると、メモリ割り当てと「ロールバック効果」に関して不正なロジックが作成される可能性があります。.希望しないときにロールバックしたことがある場合、2時間分のコマンドラインの意味を理解できます。ジョブ処理をメモリに割り当てなかったため、スクリプトはFubar版です。

2つ以上の物理プロセッサ（たとえば、デュアルコア以上）とddr3 ramがある場合、これで問題ありません。重いグラフィックスを実行していない限り、その場合、そのパワーロードが問題を引き起こしているのであれば、updatedbがリストの最後になります。何らかの理由でシステムへの動きを偽装しようとしている場合、updatedbを無効にするのではなく、他の方法でそれを実行します。実際、updatedbは、システムに偽装する限り「何も起こらない」というアクションを固めます。

率直に言って、バイナリファイル/ usr / bin / updatedbのサイズに基づいており、OS内の信号/システム通信のアーキテクチャを考慮しており、Bashのサイズは相互にリンクされているシェルダッシュまたは非同期呼び出しの10倍ですシステム上で非常に安価。

記述した連続スクリプトを実行しているシェルにログインしていて、管理者（sudoなど）である場合、次のコマンドを実行します。

~$ sudo bash
:~# ./script.sh

次に、おそらくスクリプト内にローカル変数を作成する必要があります（updatedbにはroot / sudo / wheelとも呼ばれるシステム権限が必要です）。たとえば：

#! /bin/sh
# Create local variables
UPD="updatedb"

echo "Beginning Execution of sequence "

その場合、シーケンスは、あなたが書いてメインスクリプトで変数として実行している他のシェルスクリプトのSTDOUT / STDINを使用している、またはcdromからアップロード/ダウンロード/ポートする場所に個人またはビジネス管理パッケージを設定していると言いますusbまたは何でも、それは非常に大きく、それらのための個人的なインストールスクリプトがあります、あなたはupdatedbを保ちたいです。ターミナルシェルが開いているとき、それがメインアプリケーションインスタンスです。他のアプリケーションは非同期で実行できますが、updatedbは、システム/コンピューティングの全体的な需要の点で最も安価なものの1つです。何回も、特にlxdm Desk EnviroとLxtermで（それは超高速）、しかしそれだけではありません。スクリプトにupdatedbを追加することなく、システムはファイルが存在しないか、何か厄介なことが起こったというエラーを発しました。そして、私は何が好きです！

シェルは、管理するシステムよりも高速です。

その場合、次に示すように、updatedb変数を呼び出して前のシーケンスをメモリにロックします

echo "Updating local database "

$UPD

echo "Exiting script two "

exit

私が言っていることがわかりますか？実行速度テスト、つまりAndrew Tanenbaumスタイルを実行しているため、これを要求した場合。それ以外の場合は、このツールを使用してください。

— おっと
ソース

updatedbの問題はCPUまたはメモリではなく、IO帯域幅です。私の場合（優れたCPUと十分なメモリを備えたシステム）、1時間に5 MB /秒でハードドライブを1回転させ、そのドライブに依存する他のすべてを遅くしています。そして、私が探しているものを正確に知っているとき、それらは新しいようlocateなファイルなので、インデックスが付けられていることを確信できないので、役に立ちません。ファイルが古い場合はfzf、あいまい検索に進みます。

— Davidmh

0

ArchLinuxで少なくとも、ように見えるman-db.timerとは、updatedb.timerデフォルトで有効になっています（例：次のファイルが存在する）が、そこにあるno installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. [...]（からの出力がsystemctl enable {man-,update}db.timer）。

ファイルシステムに存在するシンボリックリンクは次のとおりです。
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
/usr/lib/systemd/system/multi-user.target.wants/updatedb.timer

単にそれらを削除するだけの問題であるべきです。
しかし、彼らはのアップグレード/各再/インストール時に再作成されman-db、mlocateそれぞれのパッケージ。

ArchLinuxの場合、考えられる回避策は、pacmanがそれらを削除するためのフックを持つことです。
ただし、アップグレード全体で有効にしたい場合でも、そのようなイベントごとに削除されます。
その場合、タイマーを有効にしたいときにフックを無効にすることができます。
ただし、タイマーの有効化は、パッケージの再/インストール/アップグレード時にのみ有効になります。これは、タイマー.timerに直接接続systemctl enableするデフォルトのユニットファイルにセクションが設定されていないためです。タイマーを有効にし、リンクを削除して無効にするには、
手動ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timerまたはln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timerコマンドが必要です。

を許可するセクション/etc/systemd/system/{man-,update}db.timerで提供するカスタムユニットをオーバーライドすることもできますが、リンクはre / installation / upgradeで作成され、sを効果的に再有効化します。WantedBy=multi-user.target[Install]systemtl enable|disable/usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timer.timer

systemctl mask man-db.timer updatedb.timerタイマーをマスクするために実行することもできます。
手動で実行systemctl start man-db.service updatedb.serviceして対応するサービスを開始することが依然として可能であっても、何らかの理由でユーザーがそれを望んでいる/必要としていることに気付いた場合、手動でタイマーを開始することはできません。systemdは、マスクされたユニットを示すためにシンボリックリンクに置き換える必要があるため、
この回避策では/etc/systemd/system/{man-,update}db.timer、必要に応じて存在するカスタムユニットファイルを上書きできません/dev/null。

マスキングは、最も邪魔にならない解決策のようです。アップグレードのたびに
手動で削除し、手動で有効化/無効化できるセクションを含む/usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerユニットファイル/etc/systemd/system/{man-,update}db.timerを上書きすることをお勧めします。[Install]WantedBy=multi-user.targetsystemctl

残念ながら、現時点では、少なくとも私が考えることのできる簡単な回避策はありません。
これはパッケージがあることを前提としman-db、mlocateそれらを除去することは希望/便利なソリューションではありません。システムにインストールされて維持することが必要/たかっています。

こちらもご覧ください： https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/

— alex_giusi_tiri
ソース