-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tdiary serverコマンドにログファイル指定オプションが欲しい #397
Comments
少し書いてみたのですが、サーバの種類 (thin, webrick, unicorn) ごとに処理を分けないとダメですね。
のほうが良い気がしてきました。 |
うーん、なるほど。性能等を確保したい場合にはtdiaryコマンド使うなとなると、tdiaryコマンドはあくまで開発者向けという位置づけになってしまいそう。tdiaryコマンドの扱いを明確にしないといけませんね……。 |
Railsはどうだろうと調べてみました。
tDiaryでもomniauthのセッションやbase_dirをconfig.ruに書くことから、tdiary serverコマンドは開発やお試し用に割り切るのがよいと思えてきました。 |
(ちょっと脱線) omniauth関連のissueでも気になったんだけど、config.ruの扱いも難しいですよね。tDiaryではconfig.ruも配布ファイルだけど、それを書き換えることを前提にするのは(これまでの)tDiaryの流儀からは外れてしまうという。 |
そうなんですよね。CGIでの.htaccessのような性質も持っているので、どう扱うかのポリシーを決めたいですね。 |
理想的には tdiary.conf に書いた middlewares を stack に積む機構があるとよさそう |
設定系の課題は別issueを立てるとして、いったん tdiary serverに話を戻します。 現状(わかっていること、わかったこと)
対応案
ちょっと、案3でやってみます。 |
案3のCommonLoggerでやってみましたが、RackサーバではなくRackアプリケーション側でのログ出力になるので、config.ruに指定する形になりますね。 use Rack::CommonLogger,
File.new('log/access.log', 'a+').tap{|f| f.sync = true } config.ruは書き換えない前提として、
という方針でどうでしょうか? |
見落としてました、すみません。 「tdiary server コマンドは今のままにする」ってのはWrbrick専用で--logオプションがある状態という意味ですね? であれば現状はそれで良いと思います。 |
これはどういうステータスなんでしたっけ? 「config.ruの別ファイルへの切り出し (#476) が実現したら、tdiary側でもログを出力できるようにする」がまだかな? |
はい、そうです。 |
じゃあ延期しておきます |
現在 $stderr 決め打ちだが、ログファイルを指定できた方が良い。
ローテーションとか考え始めると面倒になるけどそれは別途。
The text was updated successfully, but these errors were encountered: