はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
先日のShibuya.pm #9のLightening Talkで「gdbでXS on mod_perlをデバッグ」という話をしてきました。XSを使い出すと、従来のPerl的デバッグだけでは不十分なのでgdbをうまく使って、効率的にデバッグしましょう、という話です。実は、はてな社内では1年近く前に勉強で話したネタだったのですが、ようやく公開することができました。 Shibuya.pmでは5分という枠があったのでショートver.でしたが、ここでは制限はないので、本来のロングバージョンの資料をアップします。ちょっと公開できない情報が混っていたので、xxxで隠していますが、ご了承ください。 ちなみに、Rubyとかでも似た感じでデバッグできると思うので、そちらの人も参考にしてください。長いよ!という人は、最後の「これは設定しておけ的gdb初期化マクロ」だけでもどうぞ。かなり便利です。 (資料公開が
なんか良く分からんけどSegmentation faultが出て泣きそうだったんだけどやっと原因がわかったっぽい感じなのでメモしとく。 とりあえず環境は下記 CentOS 5.2 Apache 2.2.9 Perl v5.8.8 mod_perl 2.0.4 MySQL 5.0.51b 現象としてはサイトを数時間放置してアクセスすると必ずセグるというもので、当初は何がなんだか分からないL状態でした。 で、coreファイルを解析したところ、 Program terminated with signal 11, Segmentation fault. #0 0x048be024 in mysql_send_query () from /usr/local/mysql/lib/mysql/libmysqlclient.so.15 というメッセージが。どうやらmysqlに問題があるっぽいことがわか
Apache1.3 + mod_perl を構築して、/(ルート)にアクセスした時点でエラーが発生しました。 logs/error_log [notice] child pid 17208 exit signal Segmentation fault (11) googleで検索するとPHP関連が多くHitしましたが、今回はPHPはインストールしていません。 で、原因はというと、mod_perlのインストール方法にあったようです。 × なインストール手順 cd /usr/local/src wget http://perl.apache.org/dist/mod_perl-1.0-current.tar.gz wget http://archive.apache.org/dist/httpd/apache_1.3.36.tar.gz tar xzvf apache_1.3.36.tar.g
![[notice] child pid 12143 exit signal Segmentation fault (11) - リンギオ](https://cdn-ak-scissors.b.st-hatena.com/image/square/b39a97b35fc50a748aa6ade2199bec180db9b11e/height=288;version=1;width=512/https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fogimage.blog.st-hatena.com%2F17680117127040067259%2F17680117127040090125%2F1555461844)
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
無名の遺跡15 建物が解体された土地を訪れると、時々、塀やコンクリートの基礎などが撤去されずに放置されているのを見かける。 このような過去の痕跡が残されている空き地を、本ブログでは"無名の遺跡"と呼んでいる。 無名の遺跡が生み出される原因の多くは、解体や撤去費用を抑え…
mod_fastcgiとmod_fcgidは差がなくて、mod_perl/mod_speedycgiが一歩前に出てるという感じですね。worker動作（スレッドモデル）となると、対応しているのは mod_perl2 vs mod_fcgid だけ。mod_perl2 はいかんせん導入が面倒くさいので、手軽さでは mod_fcgid の方がよいのかもしれません。 本格的にパフォーマンスを求めたり、高負荷時のメモリ消費量の少なさを考えると mod_perl2 on worker MPM に優る選択肢はないのですが個人では必要ないでしょう。*2 ただ、どれも Apache にモジュールを組み込まないとならないので、お手軽に高速化したい場合はSpeedyCGI（ソースコード）をオススメします。パフォーマンスも（個人で使うには）十分ですし、Apacheからは完全にcgiとして見えるので（プロセスが完
【覚書】 Catalystアプリをmod_perl環境で実行するためにApacheのhttpd.confの設定 とりあえず、Webサーバへのアクセスがmod_perlで処理されるようにするには以下のようにhttp.confに設定を追加もしくは書き換えする。(つまり、http://localhostにアクセスするとCatアプリが呼ばれる） -------------------begin DocumentRoot "/var/www/TR" LoadModule perl_module modules/mod_perl.so PerlSwitches -I/var/www/TR/lib PerlSetEnv TR_DEBUG 0 PerlLoadModule TR SetHandler modperl PerlTransHandler TR PerlResponseHandler TR re
Soozy - mod_perl専用Webフレームワーク 自分が使ってるフレームワークをいきなり晒してしまうテスト。 perl5なコードを初めて書いた時に最初に作ったやつです。 最初はSledgeを使おうとも思ったんだけど、なんか色々とやってくれるのが疎ましくて Sledgeの肉をそぎ落として、自分が使う最小限なものだけを実装した感じになってます。 一部Sledgeからコピペした物が、そのまんま残ってます。 フレームワーク自体の拡張性はあまりない感じ。 tech.yappo.jp/download/Soozy.tar.gz ドキュメントも何もないのはひどすぎると思ったので BulkYAで実際に使っているコードも晒します。 BULKYA::Handlers BULKYA::Handlers::Search httpd.con <Location /app> SetHandler perl-s
mod_perl 2.0 のサーバ起動にまつわる文書を読み込んでいました。 サーバスタートアップスクリプトは，1.0 時代のドキュメントでは「PerlRequire」記述子で読み込むように書かれていることが多いが，実行される時点が中途半端。なので，PerlPostConfigRequire を使う方が吉。もし設定ファイル自体で Perl の機能を利用しているのであれば（普通そこまでコアなことやらなくて済むんだけど），PerlConfigRequire を使うとサーバ設定フェイズ（すなわちかなり早い段階）で実行される。 Apache 2.x では，graceful restart がうまくいくことの確証を得るために，一度サーバ設定フェイズが終わると，Apache 自身を再起動する。ということは，サーバ起動時に，スタートアップスクリプト等は 2 回実行される。このことで困るってことはたいていな
開発中は Apache2::Reload 使うと，変更されたモジュールを検出してリロードしてくれて便利なんですが， Class::Data::Inheritable と相性が悪い Apache2::Reload が reload した場合，mk_classdata() が呼び出されないので，クラスデータを使うとエラーが起きる（Not a CODE reference とか怒られる） スクリプトの記述にエラーがあった場合，Internal Server Error になってしまう 初回に読み込まれるときはちゃんと Response ハンドラでトラップできるんですが，Apache2::Reload が reload した時はトラップできませんされません などの弊害があります。前者については Class::Data::Reloadable なるモジュールがあるんですが，うまく動かない気がします。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
