さとぴーの選択範囲

短時間で投稿できるものを中心に記事にしていこうかと。

今日は苺を買いました。
苺ヨーグルトにするので、へたをとって手際よく三角コーナーに入れていきます。

苺

OTL。

サーバ

とあるサイトのCGIから自動発信される筈のメールが来ないので、あれこれ調べて、もし自分でCGIのファイルを誤転送していたら大変だと真っ青に。

原因の特定の為に、その複雑なCGIからのメールの動作を確認するよりも、簡単な掲示板を設置して、

# sendmailのパス(メール通知する場合)
$sendmail = '/usr/sbin/sendmail';

と指定。掲示板に投稿してメールが来ればサーバは動作している事になり、問題のメールが来ないCGI側のトラブルだという事になります。

ところが、テストで設置したCGIからもメールが来ない。

サーバのサポートに電話すると、「CGIはご自身で」「複雑なCGIのようなので、なんともいえない」KENTのCGIを設置してテストしたというと「KENTさんのCGIのサポートはKENTで」という。

なんとか、sendmailが動作していない可能性を状況報告。

どうやら、メールはサーバから送信されていたようです。ただ、送信されてから、1時間後に届いたりと不安定。

しかし「個別メールの遅延はプロパイダーのメールの問題、サーバの問題では無い。」という。

しかし、そのサーバのCGIからのメールだけ遅れて届くので、サーバの問題の可能性はやはり高いと思います。

無料レンタルサーバのland.toに設置した気軽にお絵かきですら、投稿があればすぐにメールが届きます。

@niftyのメールだけ不安定だったわけでもなく、複数のプロパイダー、メールアドレスで、投稿から受信できるまでにはやり1時間程度かかっていた事もわかりました。

やはりサーバ側の問題だったと思うのですけれど、電話対応していた人はとりあえず、「サーバじゃない」といえば帰宅できる訳なんですよね。あるいは知識不足だった可能性もあります。

今ではパソコンのハードディスクは使っていくうちに断片化するので、遅くなってしまうという認識がひろまっていて、デフラグを実行したりする訳ですが、1980年代にハードディスクを搭載したワープロ専用機があって、「使っているうちに遅くなる」という問い合わせに「操作のほうが早くなったので、遅くなったと感じているんじゃないんでしょうか」と回答。

確かにデフラグもなかったから、動作を早くするには初期化しかなく、その対応をしていたら大変な手間になっていたのも確かです。今となっては、あのときのサポートの人は…と思われているかもしれません。

ハードディスクが壊れた時、データーのバックアップはお客様でという但し書きがあったとしても、出張訪問してハードディスクを読める状態にした時、バックアップはどうしてもカスタマーエンジニアが行う事が多かったのですが、ハードディスクを読める状態にもっていく技術があると、バックアップに数時間費やす事になり、復旧できないままだとすぐ作業が終わって工賃は同じだったという経験もあります。

技術のいらない方向で、ユニットを調整するのではなくて、交換して部品代を含めて高額請求したほうが利益があがり作業が楽という話もありますね。

最近はユーザの目が厳しいので、逆にちゃんと新品のユニットで交換してしまうのが当然なのかもしれませんが昔は部品(ユニット)代も半端ではなく高かったのです。

で、やっぱりメールの遅延はサーバの(ry