Vine Linux バグトラッキングシステム

課題の詳細を表示 コメントにジャンプ ] 課題の履歴 ] 印刷 ]
IDプロジェクトカテゴリ登録日最終更新
0000204Vine Linux1 バグ2006-09-20 16:372006-11-14 10:37
報告者anonymous 
担当者 
優先度再現性不明 
状態完了解決状況保留 
バージョン4.0beta 
修正予定バージョン修正済バージョン 
概要0000204: locateコマンドがすぐに使えない
説明確認させてください。

インストール後、ファイル検索をしようとlocateコマンドを打ってみましたが、すぐには利用できませんでした。

suで、updatedbコマンドで使えるようになりましたが、こういう仕様なのでしょうか。

確か3.2まではすぐに利用できたものと思いますが(違っていたらすいませんm(_ _)m

一度updatedbを作成し、/etc/updatedb.confの

DAILY_UPDATE=no を DAILY_UPDATE=yes にすると、cron.dailyで日々データベースが更新されるようですが。

仕様でしたらそれに合わせますです。
タグ設定されていません。
archx86
パッケージなし
添付ファイル

- 関連

-  コメント
(0001280)
daisuke (管理者)
2006-09-20 17:45

> 確か3.2まではすぐに利用できたものと思いますが(違っていたらすいま
> せんm(_ _)m
>
> 一度updatedbを作成し、/etc/updatedb.confの
>
> DAILY_UPDATE=no を DAILY_UPDATE=yes にすると、cron.dailyで日々
> データベースが更新されるようですが。
>
> 仕様でしたらそれに合わせますです。

デフォルトで止まっているのは仕様ですが、動いていたほうがいいですか?
かなり重い処理がうごくことと、夜間電源を落としていた場合次回起動時
に anacron で実行されるのであまり好ましくないというのが理由です。
ですので必要に応じて実行でいいのではないかと思っています。
(0001281)
anonymous (参照)
2006-09-20 22:29

> デフォルトで止まっているのは仕様ですが、動いていたほうがいいです
> か?
> かなり重い処理がうごくことと、夜間電源を落としていた場合次回起動
> 時
> に anacron で実行されるのであまり好ましくないというのが理由です。
>
> ですので必要に応じて実行でいいのではないかと思っています。

すいません、自分の環境のことでしか考えておりませんでした。m(_ _)m

普段はサーバー用途で付けっぱなしで使用しており、夜間電源を落とした使用まで考えませんでした。

ということで、この件、必要に応じてでOKです。

デフォルトはその方が色々なユーザーには良いですね。

locate以外のコマンドも他にありますし・・・
(0001282)
anonymous (参照)
2006-09-28 19:54

ntfsをマウントしている場合や、USBメモリなどの抜き差しでsupermountが異常終了した場合に、slocate.cronが原因でフリーズする(またはapt-get updateが正常に終了できない、ないはずのディバイスが使用中でumountできない、dfで固まるなど様々な障害)報告は、過去に何度かあったので、フリーズするよりは、locateでデータが古いエラーになる方が、初心者に優しいと思います。
参考:
http://search.luky.org/vine-users.5/msg09385.html [^]
http://kobashi.law.kobegakuin.ac.jp/linux/#200600121-1 [^]
http://search.luky.org/vine-users.6/msg08940.html [^]
http://mlog.euqset.org/archives/vine-users/072709.html [^]
(0001283)
anonymous (参照)
2006-10-31 21:45

いや、最初から locate が使えた方が初心者にやさしいでしょう。
と言うより、locate みたいな便利なコマンドが使えなかったら、
誰だって困るんじゃないでしょうか。そして、/etc/updatedb.conf
の修正なんて、初心者に思い付くわけがない。

たしかに、cron 実行中にフリーズするのは困ったことで、考慮に
入れなければなりません。でも、見に行かないパスや、見に行かない
ファイルシステムを多少大事をとって指定しておけば、たいていの
ユーザのところでは大丈夫ではないでしょうか。ローカルな
ハードディスクの Linux のパーティション以外をデータベースに
登録したい人は、自分で設定する。その場合は当然、自己責任と
いうことで。

また anacron でかなり重い処理が動くといっても、バックグラウンド
で動くのですから、私は気にしたことがありません。必要なときしか、
パソコンの電源を入れないという使い方ですけれど。

--
長南
(0001284)
anonymous (参照)
2006-11-09 21:39

> 誰だって困るんじゃないでしょうか。そして、/etc/updatedb.conf
> の修正なんて、初心者に思い付くわけがない。

そうではなくて、ここでの論点は、初ログイン直後、またはlocateを使う
前に# updatedb を実行しなければならないのは、よい仕様かどうかでしょう。
/etc/updatedb.confの修正は、自己責任でやりたい人がすればよい。


> 入れなければなりません。でも、見に行かないパスや、見に行かない
> ファイルシステムを多少大事をとって指定しておけば、たいていの
> ユーザのところでは大丈夫ではないでしょうか。

OSがフリーズするリスクの回避よりも、初回にlocateが実行できるかど
うかの方が優先されるのは理解できません。8日以内であれば2度目以降
は問題がない。まぁ、でも、/mntと/mediaを見に行かないようにするの
であれば、DAILY_UPDATE=yesはありかもしれません。
(0001285)
anonymous (参照)
2006-11-14 10:37

失礼、返事をいただいたことに今気がつきました。

> > 誰だって困るんじゃないでしょうか。そして、/etc/updatedb.conf
> > の修正なんて、初心者に思い付くわけがない。

たしかに、これは変な理屈でした。locate を実行すれば、
「/etc/updatedb.conf を編集しろ」というメッセージが
出るのですから。しかし、私が言いたかったのも、次の文章と
同じことです。

> そうではなくて、ここでの論点は、初ログイン直後、または
> locateを使う前に# updatedb を実行しなければならないのは、
> よい仕様かどうかでしょう。

最初から、locate が使えるようになっていた方が、誰にとっても
便利な(とくに初心者に親切な)仕様だと思います。

> OSがフリーズするリスクの回避よりも、初回にlocateが実行
> できるかどうかの方が優先されるのは理解できません。

私自身「たしかに、cron 実行中にフリーズするのは困ったことで、
考慮に入れなければなりません」と書いているのですけれど。
「フリーズするリスクの回避」以外に slocate.cron を実行
しないようにしておく積極的な理由が、私には思い付きません。
anacron でかなり重い処理が動くとしても、今どきのマシンなら
一分かかるか、かからないかでしょう。

たしかにマシンがフリーズする確率が高いならば、slocate.cron
を勝手に実行するわけにはいかないでしょう。しかし、フリーズする
心配がほとんどないのならば、ユーザが特別なことをしないでも
locate を利用できる方がよいのではないかと、思うわけです。

> まぁ、でも、/mntと/mediaを見に行かないようにするの
> であれば、DAILY_UPDATE=yesはありかもしれません。

そうしておけば(あと、nfs ファイルシステムを除外しておけば)、
たいていの人のところで大丈夫だと思うんですけれど。

--
長南

- 課題の履歴
変更日 ユーザー名 項目 変更内容
2006-09-20 16:37 anonymous 新規課題
2006-09-20 17:45 daisuke 状態 新規 => 完了
2006-09-20 17:45 daisuke 解決状況 不明 => 保留
2006-09-20 17:45 daisuke コメント追加: 0001280
2006-09-20 22:29 anonymous コメント追加: 0001281
2006-09-28 19:54 anonymous コメント追加: 0001282
2006-10-31 21:45 anonymous コメント追加: 0001283
2006-11-09 21:39 anonymous コメント追加: 0001284
2006-11-14 10:37 anonymous コメント追加: 0001285


Copyright © 2000 - 2024 MantisBT Team
Copyright © 2012 - 2024 Project Vine
Powered by Mantis Bugtracker