質疑応答因果応報拡散未希望10 byト

ipv6サーバの_serviceが溜まってきてるのとLA記録が1日1回だけになってるのは
何か関係があるんだろうか？

2011年1月からipv6鯖のf22が毎日深夜2:50のログ掃除をしてないから。
せきざわあきら騒動でqb6からqb7に移った時にちゃんと対応しなかったんだと思う。
外から見えないけど_service以外にも貯まってるものがありそうだけど多分直ちに影響はない。
BBS.CGI - 2013/08/08になってるから一応トオルちゃんが鯖いじった事はあるみたいだけど
海外ISP判定がぶっ壊れてて●が無いと書けない模様、いや今は誰も書けないかｗｗ

あ、LA記録が1回になってるのは1日1回しかf22が動いてないから。
f22baseから1回しか呼ばれてないのか他は無視してるだけなのかは分からない。

ごめんそもそもf22baseからは呼んでなかったわ。cronか何かで回してるのかな。
http://f22base.2ch.net/_work/server.txt

多分cronで回してると思う、ログを見る限りf22は毎日1時過ぎくらいに一度しか回ってない。
板を順番に回って掃除するはずのｆ22だけど、ipv6trからipv6へ順番が回ってない、なのでserviceが掃除されないしLAも記録されないんじゃね？
前に別の鯖であったセマフォの不具合みたいになってる。

でも実際の原因は中にはいってみないと分からない、f15をぶん回すと直ったりするんじゃなかったっけ？前にそんなことやっていたような。

ふと思ったけど
f22baseからとcronからで同時に呼ばれるとか
さらにf15も同時にぶつかるとかって事になったら
どんな化学反応が起こるんだろうか？

現役鯖でもf22baseが落ちた時に詰らないように
予備cronとしてipv6鯖みたいのが動かしてありそうだし

＞さらにf15も同時にぶつかるとかって事になったら
本来その為のセマフォなんだと思うんだけど。

外側からじゃセマフォ関連なのかデータがおおすぎて処理できないとか良くわからんし、んでもf15を再稼働させたのってhayabusaだったっけ？
量が多いから処理できなかった云々はhayabusaならあるあるかもだけど、ipv6ならそんなことにはならなそうだけど。

とりあえずThe end of work.と書かれたログが2011年頃だし、ずっとまともに動いて無かったんだろうなと。

まあそうかな〜と思いつつ
セマフォがどうの〜みたいなの見たような気がしたから

IPv6からのビュー数を格納するPVv6YYYYMMDD.txt のために
ipv6鯖用カスタムを使っているのか？共用に分岐をあらかじめ付けてあるのか？
あたりで他鯖と状況が違う可能性もありそうですし

んでセマフォのチェックが必要になる同じ処理を全部f15に押し付けて
衝突の危険性を減らしたのはhayabusaだったような気がする
http://qb7.2ch.net/test/read.cgi/operate2/1294741755/341
頻繁に落ちていたどこかにも後に移植してたようなないような？

ipv6鯖のLA記録が1時間置きになった〜

でもなんか時刻設定とかサマータイムのプロファイルあたりが
ちょっとズレてるっぽい？

最新の記録が
> 2013/09/07 15:46:49 LA= 3:46PM
って未来になってるような…

時刻がずれてるときって荒らしたりしてもログの照合ができないよね？
流出データ見ていてそう思った

なんか時間がバラバラすぎて外部から適当に叩いてるように見える；

一度外部から叩いてみたら、セマフォとかじゃなくてエラー吐いて途中で止まるみたい。
まともに直すには中に入って作業しないと無理カポネ

作られてから随分経つ鯖だし誰かメンテして欲しいけど、こいつは特殊な鯖だしむつかしいかなぁ
つかこの板tracerouteのテスト結果貼る位しか使ってないんじゃねｗ

bbs.cgiが中途半端に更新されてるから誰かがいじっているのは間違いないけど
海外ISP判定がぶっ壊れててかつ●が死んでる今誰もあの板に書けないよね多分。

わざわざThread::Semaphoreモジュールを入れて描いてあったのを覚えています。
そこまでシビアな排他処理が必要なの？って思っていました(･∀･)