トップ 追記
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|10|12|
2009|02|03|06|07|10|11|12|
2010|01|02|03|04|07|09|10|11|12|
2011|01|03|04|05|06|07|08|10|
2012|01|06|08|09|10|12|
2013|01|02|03|04|07|09|11|12|
2014|01|03|04|05|06|09|
2015|04|
2016|01|08|
ここは旧えびめもです。えびめも2に移行します(2016/12/1)

2016年08月24日

BRM213 松阪200 ブルベデビュー

何にでも初めてはあるだろう。始めなければ始まらない。ブルベに申し込んで2ヵ月がたった2016年2月13日。JR松阪駅で朝6:30ブリーフィング。7:00出発。6:00には到着しておこうと思う。今までの練習で200kmは走れるようになったので完走できる自信はあったけど緊張がやまない。前夜布団に入っても寝付けなかったので深夜のうちにクルマで松阪へ移動し車中泊を選択。しかし結局クルマでも寝付けなかった。


6:30 ブルベカードが配られてブリーフィングが始まる。気温は10度前後と2月にしては暖かい。湿った風が入り込み午後から100%の降水確率だ。約半数の人が出走キャンセル(DNS; do not start)を選択したらしい。 ということは、ここに集まった人たちは「雨上等」なヘンタイさんばかりだ。

朝7:00になり、車検の列に並ぶ。前照灯、尾灯、ベル、ヘルメット、反射ベスト。規定通り装備していることを確認してもらってブルベカードにサインをもらい、いよいよブルベがはじまる。


スタートして50m。最初の角を曲がったところでタイヤに空気を入れていない事を思い出す。しまった。車にポンプが積んであって出発前に入れようと思って忘れていた。50mで気が付いてよかった。これが3kmほども進んでいたら、そのまま行くか戻るか悩んでいただろう(パンク修理用の携帯ポンプは備えてあるが)。すぐに駐車場へ引き返してポンピング。車の鍵を探すのに焦り、しまうのにも焦って5分のロス。再スタート。もう誰もいない。いきなり独りぼっち。最初くらい追おうと思ったのに。

僕をブルベに誘ったK氏もいた。当然スピードが違うが最初の数キロくらいは追うと思っていた。K氏には今日はもう会うことはないだろう。開始10秒でまさに瞬殺だった。しょんぼりだ。仕方ない一日は長いと思いながら走っていると初期点検のため停車している人が数名。雨が早くもパラパラと降りだし、レインウェアに着替える人もいて、ほどなくして後方の列車に合流した。

おおー、やっぱり楽だ。一人目より二人目、二人目より三人目。後ろになれば空気の流れができて、ギア2段ほど楽になる。集団走行自体、このときが初体験だった。


平地ではトレインだが登りになると脚の差で集団がばらつく。いつの間にか前後が離れて一人になっていた。

200kmブルベでの制限時間は13時間半以内。途中数か所のチェックポイント(PC: Point de Controle 仏語)で足切りのclose時刻が定められている。PCは主にコンビニで、レシートの打刻時間で制限時間内での通過を証明する。


47km地点最初の通過PC到着。良かった。参加者がたくさんいた。よく見るとK氏が出発するところだった。あれ? なんで? 聞くところによるとシフトワイヤが切れて修理した。前輪のハブもグラグラしているので慎重に漕いでいるとのこと。修理時間のロスタイム+慎重に漕いでいるといっても先にいるのはさすがだなと思うと同時に、予備のシフトワイヤと修理工具を持っていることに驚いた。ブルべは準備8割と聞くが、タフに走り続けるってのはそういう事なんだなと勉強になった。

軽い勾配の登りを終えると本日の最高標高地点に到着。あれ、あっけない。これでもう終わり? そんなはずはなかった。海岸線まで標高を下げた後、入江と入江の間にあるup/down区間に突入。登っては下り、登っては下り。今日は標高の高い峠には登らないが、獲得標高が2400mもある。他の参加者を見ていると短い登りでもインナーギアを使っている。無理してアウターで登ることないのか。

賢島の手前で平地になり、久しぶりに表れた信号停車で列車に追いついた。後尾についてちょっと休憩させてもらう。良く見ると先頭を引いているのはどうやらお嬢さんのようだ。速度計を見ると32km/h前後。こっちは後ろにいるから付いていけるけど先頭はきついんじゃないか。軽い上り坂でも30km/hで引く。列車が前後に伸びる。PCに指定されている展望台への最後の坂は激坂だった。坂をアタックする前に食事をしておけばよかった。おなかが空くと力が出ない。ハンガーノックという。

展望台のPCでお嬢に挨拶した。引いていただきありがとうございました。聞くところによるとブルべは月イチペースで200, 300, 400, 600kmの認定を持つSRなお嬢さんだった。パリへは?と聞くと、「600を一度走ったくらいじゃパリは無理です」とのこと。そうなのか。でもお若いからまだ先いくらでもチャンスはありそうだ。


景色のよい展望台でコンビニおにぎりを食べて休憩。いー気分だ。114km地点で6時間。残り制限時間は7時間半ある。トラブルなければ大丈夫。


午後から雨が本降りに。志摩の漁港。車では通れないような路地を抜け、パールロードの側道を通り、景色のよい丘へ連れていかれたと思ったら再び漁港まで標高を下げる。


up/down, up/down。永遠と続く感じ。晴れてたら気持ちいいだろうな。雨だと怖い。ブレーキ効かないし、細い道のブラインドコーナーから対向車がやってくる。急ブレーキ。


パールロードを終えて鳥羽水族館まで来れば、あとは平地だ。信号停車で7-8人の列車に合流した。国道42号線。意外とクルマの多い道を集団走行する。ドライバーから見れば、こんな雨の日に目立つ格好でなんでチャリンコなんだろう?と不思議な光景だろう。信号も多い道でこまめに信号停。先頭から順にハンドサインが出る。止まるときは手を背中に当てて後方に知らせる。僕も真似をした。最後尾だけど。 頑張ってーと歩道から声をかけてくれた女子がいた。先頭を引くAudaxジャージのお兄さんあてだと思うけども後ろにいたおっさんも少しうれしかった。

集団の中頃にどうやら故障車がいるようで、20-25km/hほど。カンパ君が脚を余らせフリーをギーコギーコ鳴らしながらのかなりのノンビリ走行だった。どうやらこの集団はタイムアウト以内の完走を目指す列車のようだ。楽だけど、ここにいたら遅くなる。練習はいつも一人で走っていたじゃないか。

集団から離れて前に出る。とたんに両耳に入ってくるノイズが違う。新鮮で冷たく厚い空気が襲ってくる。ああそうだ、この感じだ。徹夜明けの異常なテンションが手伝い170kmを超えてから30km/h目標に漕ぎつづける。


最終PCのファミリーマート。残り22km。在庫薄いしアイスショーケースは電源切られているし、閉店間際のコンビニ感だった。来年には無いだろう。レシートチェックがpm5:44。休憩を15分とし、pm6:00発と決める。目標12時間のためには、pm6:00に出てpm7:00に到着しなければならない。22kmを60分だとかなり頑張らないといけない。

カップ麺を食べている人を多く見た。体を冷やさないためにカップ麺は良い選択に思えた。塩分も糖分も欲しい。僕はここでもまたおにぎりと温かいお茶。久しぶりのトイレ。雨具を着込んでいたのでずっと我慢していた。

ブルベカードにここまでの通過時刻を書き込み最後の装備チェックをして時計を見ると pm6:05。やばい。5分オーバー。目標12時間は難しくなってきた。暗闇の中へ急いでスタート。ケータイ鳴った気がしたけどごめんなさい、取れません。距離計が200kmを超えた。無常にここで時計がpm7:00。目標時間には間に合わなかったが、無事にゴール地点に滑り込んだ。13時間半以内に200km完走だ。

「Finish時刻」は「受付場所に入った時刻」を自分でブルベカードに記録するとのこと。その時刻を覚えていなかった。目標のpm7:00すぎちゃったので、pm7:01でもpm7:10でも大差ないと思い、「pm7:05くらいだったと思います」、とゴール受付のオダックス近K野さんに言うと、「そんないい加減なことじゃ駄目だ」と注意を受けた。(注;今思えば当然だ)


ともかくもブルベ初挑戦は 後半雨の中で12時間5分 で認定完走となった。これが僕のブルベデビュー戦だった。


2016年08月23日

自転車の話1_自転車面白い

超久しぶりの更新です。

昨年(2015年)の夏に通勤用に中古のクロスバイクを買いました。12,000円でした。それまでママチャリ(パパチャリ)で通勤していましたのでクロスバイクに乗り換えた途端、その軽量さに感激し、突然自転車というものにハマってしまいました。

その勢いで2ヶ月後の2015年10月からロードバイクに乗り初めました。といっても何十万もするものをいきなり買えるわけもなく、全部込みで10万以下のクロモリロードでまったりとロングライドを楽しんでいます。クロモリロードはスピードは出ませんが旅をするのにはとても良いものです。


自転車のロングライドのイベントの一つに「ブルべ (Brevet)」というものがあります。自転車を使ったスタンプラリーのようなもので、指定されたコースを指定時間以内で回ってくるとフランスの本部(ACP)から「がんばったね」と認定(Brevet)されます。

ブルベはレースではく、サイクリングイベントなので交通ルール厳守です。赤信号停止はもちろん、右折も基本は二段階右折。かっ飛ばす必要はありません。

ブルべのルールは世界共通で、200km (制限時間13時間半) が登竜門です。その先は 300km, 400km, 600km, 1000km, 1200kmという世界があります。一年間で200から600までを完走すると SR シューペル・ランドヌール 英語ではスーパーランドナーに認定されます。

SR (600km完走!!)なんて夢のまた夢で、何年も先にひょっとして取れたらいいな。と思い描き、まずは200kmの完走を目指して挑戦を始めました。

2015年の冬は200kmを完走できることを目標にして、過去に実施された名古屋近辺の「ブルべ」の地図をネットで調べて走り込んでいました。最初は130kmを走るのに13時間かかりました。首が痛くなり一週間ずっと日常生活に支障がでました。12月の寒いころに、200kmをなんとか12時間で走れるようになってきました。

「ブルべ」の参加申し込みは2ヶ月ほど前です。200kmは人気があるため申し込み開始日に埋まってしまうとのこと。ビビりながら2016年2月の松阪200kmの申し込みを12月に行いました。

そして迎えた 2016年 BRM213 松阪200km (伊勢) 僕のブルべデビュー戦。

もう半年も前の2016年2月13日の話ですが、忘れないうちに書こうと思います。


2016年01月28日

gnuplotで日本語の表示

また8か月も書いてなかった。乗っ取られてなくてよかった。

gnuplot PNG端末へ日本語(UTF-8)の表示

環境 debian 6.0 squeeze
 
set terminal png size 1200,480 font "/usr/share/fonts/truetype/ipafont/ipagp.ttf" 8
普通にやればokだった。上記フォントファイルは用意しておくこと。
# dpkg -S /usr/share/fonts/truetype/ipafont/ipagp.ttf
ttf-ipafont-gothic: /usr/share/fonts/truetype/ipafont/ipagp.ttf
# apt-get install ttf-ipafont-gothic

2015年04月15日

linux-4.0

半年間も書いてなかった。。。orz
linux-4.0がリリースされました。linux-3.20のリネイムとの事で、大きな変更はないとのことです。

自分とこのCAT724でも動作するようにしました。CAT724ユーザの方、遊んでみたい方はこちら
http://www.si-linux.co.jp/catwiki/index.php?CAT724_linux-4.0.0

2014年09月06日

mobile shower

山登りして登山口(駐車場)に降りてきたあと、手足を洗いたいが水場があるとも限らない。車に水タンクを積んではいたが、ちょうどいい高さに水タンクを置く場所が無かった。という動機で作った(というほどでもないけど)。

材料

ホムセンで購入。キャリア、水タンク、ホース、ホースフック、灯油ポンプ。
工進 石油給油ポンプ 「直付 自動停止」 EP-303F

工進
¥ 1,249


使ったメイン部材はこれ

セットアップしたところ。ここまでは工具無し。技術力ゼロ。

このままでも使えるけど、灯油ポンプは満タンになると自動停止する機能がついているので殺すことにする。分解したところ先っちょのフロートへ行っている線を切って電池ボックスに短絡するだけで良さそう。

先端をホースに替える

みんな大好きインシュロックでフックをつけて完成

課題

灯油ポンプの取り説によると灯油以外には使用しないことと記載がある。水だと腐食するかもしれないので使わないときは水を抜いておいたほうが良さそう。揚水能力は1m程度。頭から水かぶりたいときは高い所に置く必要あり。


2014年06月10日

booting wheezy on linux-2.6.34 fails.

udevd[497]: unable to receive ctrl connection: Function not implemented
udevd[497]: unable to receive ctrl connection: Function not implemented
udevd[497]: unable to receive ctrl connection: Function not implemented
the same problem is here. http://www.plugcomputer.org/plugforum/index.php?topic=5965.0
it seems to accept4() returns an error.
a patch is here.
https://github.com/gentoo/eudev/issues/7
diff --git a/src/udev/udev-ctrl.c b/src/udev/udev-ctrl.c
index a235912..01747b1 100644
--- a/libudev/libudev-ctrl.c
+++ b/libudev/libudev-ctrl.c
@@ -189,6 +189,18 @@ struct udev_ctrl_connection *udev_ctrl_get_connection(struct udev_ctrl *uctrl)
         conn->uctrl = uctrl;
 
         conn->sock = accept4(uctrl->sock, NULL, NULL, SOCK_CLOEXEC|SOCK_NONBLOCK);
+
+        /* Fallback path when accept4() is unavailable */
+        if ( conn->sock < 0 && (errno == ENOSYS || errno == ENOTSUP) )
+        {
+                conn->sock = accept(uctrl->sock, NULL, NULL);
+
+                if (conn->sock >= 0) {
+                        fcntl(conn->sock, F_SETFL, O_NONBLOCK);
+                        fcntl(conn->sock, F_SETFD, FD_CLOEXEC);
+                }
+        }
+
         if (conn->sock < 0) {
                 if (errno != EINTR)
                         log_error("unable to receive ctrl connection: %m\n");
also include fcntl.h

2014年05月25日

某唄

落ち始めたアプリは ファイルを消して

真っ青な画面に ひとつのエラー

風が心にささやくの

このままじゃ バグなんだと

とまどい 傷つき

誰にも 打ち明けずに 悩んでた

それももう 逃げよう

ありのままの エラー見せるのよ

ありのままの バグになるの

何も怖くない 風よ吹け

少しも悪くないわ

悩んでたことが うそみたいね

だってもう自由よ なんでもできる

どこまでやれるか

顧客を試したいの

そうよ変わるのよ 仕様

これでいいの これは仕様ですから

これでいいの 仕様信じて

非難あびながら 歩きだそう

少しも懲りてないわ


2014年05月12日

BeagleBoneBlackBox環境試験

BeagleBoneBlackをご利用の皆様。-45度から90度で試験いたしました。保証値ではありませんが実力評価指標値の一つとしてご理解ください。振動試験も行っています。
http://www.si-linux.co.jp/techinfo/index.php?BBBBox_%B4%C4%B6%AD%BB%EE%B8%B3

2014年05月01日

WDTを外付けする話

WDT(watch dog timer)いわゆる番犬。コンピュータが故障した時に出力が出っぱなしでハングアップするとかなりヤバい。例えばアクセル踏みっぱなし、モーターが回りっぱなし、ドアが開きっぱなし、毒物の排出弁が開きっぱなし。。。機械である以上は故障モードについて考慮する必要があり、壊れたときには停止(off)のモードに強制的に移らねばならない。そのために利用されるのがWDTである。


WDTは一定時間内(通常なら数秒以内)にクリア命令を発行しなければコンピュータを強制的にリセットするものである。コンピュータが故障していないときは常時WDTをクリアし続けている。たいていのCPUにはWDTが内蔵されている。CPUに内蔵されたWDTはCPUクロックを基準に動いている。つまりCPUクロックの故障モードには無防備なのである。


CPUクロックの原発振水晶が故障するモードではCPUも停止するしWDTもカウントアップしなくなる。出力が出っぱなしで固まってしまう。fail safeにならない。水晶発振器やその負荷容量、CPU(最近ではSoC)内の発振アンプやPLL、周波数ディバイダの故障モードでも同じくfale safeにならない。SoCそのものの故障モードにも対応できない。


CPU(SoC)内蔵のWDTはあくまでも簡易的なfail safeであって、わずかなコストをケチらず外付けWDTを搭載することは自動車業界やガス検知器といった、(ちょっとヤバそうな)組込み業界では要求基準になっている。


外付けWDTの故障モードへの対策は? はい、CPU(SoC)内蔵WDTも当然併用します。両方同時に故障した場合は? その時はきっとI/Oも壊れていて出力も止まるよ。きっとたぶん。


2014年04月30日

プロローグ(追記)

twitterで皆様からコメントを頂き感謝しています。プロセスの停止にはSIGKILLではなくSIGTERMを用いるべきとのご指摘を頂きまして、確かにその通りですが書き直すのも面倒だし下名の誤りをそのまま残しておきますので以下SIGKILLはSIGTERMだと思って読んでください。


話の発端はあるサービスをrestartさせようとしたときに他のプロセスが死んでしまった。OOMでもないしシグナルを誤配信した可能性が否定できないシナリオについて想像いたしました。別にSIGTERMでもSIGHUPでもSIGUSRでもいいんですが、シグナルハンドラを実装していないプロセス(busyboxのappletにありがち)はシグナルを受けると容赦なく死んでしまうのでPID特定とシグナル配信のatomic性についての考察になります

プロセスの安全な停止はどうするんだろ

POSIX系OSにおいてプロセスを停止させるには ps で PID を調べて kill -9 とする。と覚えたはずである。例えば hoge プロセスを停止するには
$ ps ax | grep hoge
 1000 pts/0    S      0:10 hoge
なるほど PIDは1000だな。では kill しよう。。。 しかしグズグズしているうちに hoge プロセスは自主的に終了してしまうかもしれない。その間に全く無関係なプロセスが立ちあがり、新規に pid 1000番になる可能性は十分にある。ps で調べたのち時間が経過してから
# kill -9 1000
などしようものなら全く無関係な httpd やら sshd やら bash やらを killしてしまう可能性がある。そんなお話です。

プロセスの安全な停止その2

pidを調べてkillを送る。それを一発で行う pkill というコマンドがある。pkill にも同じ問題がある気がしてきたのでソース(debian wheezy procps-3.3.3)を眺めてみた。
案の定、pkill は proc/readproc.c によって
1) /proc の下を名前で検索してPID番号を得る
2) そのPID番号に kill() 関数で SIGTERM を送る
という手順で実装されている。ここで 1) 2) 間は atomic ではない。人間がpsで調べるのと原理は同じで、手で調べるよりは高速であるが時差は生じてしまう。てことはレースコンディションが存在する。
上記の通り PID=1000 番の hoge というプロセスを殺そうとする
# pkill hoge
1) で PIDは1000だと検出するが、その直後に hogeプロセスは自らexit()した場合において
かつ、その直後に全く無関係のプロセスが生成し、偶然 PID=1000番を取得する。

2) で PID=1000 プロセスを SIGTERM するので無関係なプロセスを殺してしまう。

procps-3.3.3 を見る限り対策は施されていないし、というよりもuserlandでこの問題は対策できそうもない。
kill直前に名前の一致をもう一度再確認しようとしても

if(名前の再確認){
   // この隙間時間
   kill();
}
がゼロにならないからだ(userlandから preemtion lockもできないし)

「カーネル側でプロセス終了直後のpid番号は一定時間(10秒程度)は払い出さず再利用しないようにする」と対策をすれば万全ではないにしろ確率が低下するけれども、それだとPIDを15bitで運用している環境では毎秒数百プロセスをfork/exitするとPID番号不足に陥る。

「pkill でプロセスを殺そうとすると無関係のプロセスを殺してしまう」 という不具合は存在し得ることになる。

存在しえる問題は、いつか必ず具現化する

不具合の原因を調べていったらレアケースでこれだった。と言う事もありえるわけで、これは大きな問題じゃないだろうか。
(同じ問題は/var/runのpidファイルを用いる start-stop-daemon でも言える)

私の勘違いであるなら、どなたかご指導お願いします。 (twitter @ebihara_nagoya )

pkill追記

カーネルソースを斜め読みしてみた。
do_fork()の方は alloc_pid()からの流れで pid_namespace内で last_pid+1 しているだけのように見えるなぁ。
do_exit()のほうは
        tsk->state = TASK_DEAD;
        schedule();
としてスケジューラを呼んでいる。EXIT_ZOMBIE => EXIT_DEAD => TASK_DEAD => task_struct 消滅まで時間がかかり、この間PIDは維持されるから上記問題は起こりにくいとされているのだろうか。

あまり議論されていない

杞憂かもしれないがこの件について議論しているスレッドを見つける事が出来なかった。pkillだけではなく、Cで普通にプログラムしても同じ理屈で
 signal(SIG_CHILD, SIG_IGN);
 child_pid = fork();
 
 ... snip ...
 
 kill(child_pid,SIGTERM);
が安全である保証はどこにもないよなぁ(特に組込み機器で何もかもrootで動いている場合)。。。SIG_IGN を使ってはいけないという事だね。ZOMBIEはこのためにあるのか。

pidを64bitにすれば解決するか

21世紀にもなってなぜpidが(defaultでは)わずか32767まで(15bit)でループするのか。pidの使用/未使用は1bit単位のmap_tableで管理されている。1PAGE=4Kbyte=4096byte=32728bitのフラグで管理している(当然これはPAGE単位で増やせるがdefaultでは1PAGEである)。確かに小メモリであるし、pid=1からインクリメンタルにサーチするよりも1bit調べればよいので時間は高速である。

いっそのことPIDを64bitにしてしまえば1秒間に4ギガ回プロセスをfork()してもPIDがロールオーバーするのに138年かかるので、この問題は解決すると言っても良い。またはuuidにするか。


いずれにしても15bitでロールする環境において、プロセスを安全にkillするにはどうしたらいいんだろう。思いつかない。

追記2014-5-1

原則に戻り、
1)なんでもrootで動かしてはいけない。サービス毎にuserを作りそのuser権限で動かせば他のサービスを誤ってkillしたりできない。
2)SIG_CHILDをSIG_IGNでデタッチしない。
でも /var/run の pidファイルを信用してのプロセスの停止は問題があることに変わらないな。

uuid

PID番号によるプロセス管理は簡単だから継続するとして、プロセスが生成される毎にuuidが付加されるようにならないかな。
/proc/PID/uuid
のように。そして
# kill --uuid <UUID>
とできるようになればよさそうなのだが。

コメントを頂きました

https://twitter.com/satoh_fumiyasu/status/461766533866192896
以下のような手順はいかがでしょうか。 
(1) SIGSTOP 送ってプロセスを止める。 
(2) 止まったプロセスが目的のものか確認する。 
(3) 目的のプロセスなら SIGKILL 送って殺す。 
目的のプロセスではなかったら SIGCONT を送って再開させる。