アカウント名:
パスワード:
Linuxカーネル使っておきながら、システム全体が飛ぶって所に開いた口が塞がらないのですが。まさか、データ格納するストレージをケチった上に/var とか/home あたりにデータ書くようにしたんで起動しようにも起動できなくなってるんじゃないかとか。# 真面目に考えたら、別にデータ専用のストレージを置きますよね。# 回路コスト考えたら数百ドルも増えやしないだろうに…
で、ウォッチドッグタイマも入れないなんて、この手のシステムで考えられないですしね。信頼性を考えたら、CPU備え付けだけじゃなくて外部にウォッチドッグ入れるとかするものですが。
「システム全体が飛ぶ」とはどこにも書かれてないと思いますが…「運良く再起動することを期待する」と書かれているぐらいですから、「起動しようにも起動できなくなってる」という想像はちょっと的外れ
たぶん、Linux システムは稼働しているが、「テレメトリ情報を送信するプロセス」だけがクラッシュしているんじゃないでしょうか。
ストーリーに挙げられている「惑星協会のブログ」をざっと読んだんですが、「運良く再起動することを期待する」理由として、「リブートしたらbeacon.csvはクリアされる」って書いてます。
ブート時の処理でbeacon.csvを削除する処理が入っている可能性もありますが、それよりもcsvはtmpfsに書き込むようにしていて、tmpfsは容量32MBしかとっておらず、プログラムはディスクフルを想定していない、とかそんなとこかなーとか想像してしまいました。
#状況確認用のデバッグログを/tmpに出力するようにしておく、というのは自分にとっては「あるある」です。本番で削除するのを忘れないようにしないと…
再起動指示受け付けないってあるから、他も巻き込んでるような。mmapでファイル扱ってパンクとか。でもcsvに15秒に一回書き込みで使わないよな。
今回のやつがそうだとは断定できないけどマルチタスクにおけるウォッチドッグタイマというのは結構めんどくさい・各プロセスが正常に動作しているか監視するタスク・監視タスクが異常を検出せず、自身が正常に動作していたら外部ウォッチドッグを叩く監視条件に間違いや漏れがあったらアウト。経験少ないと組み合わせ爆発起きやすい実装しちゃうことも間々あるものです。
最下位のidleタスクでウォッチドッグを叩くそれが止まったら再起動単純に止まったものを再起動させるのがウォッチドッグ・タイマー
そうなんですが、大抵の…Linuxカーネルなんか特に…Kernel Panicになったら、WDT叩かなくなるのでWDTが起動して強制再起動云々に入るし、そこまで行かないとしたら、地上との送受信を担当するタスクまで停まるというのが何なんだろうという感じがあるんですよね。そこら辺の対策のためのコードというのは、Linuxカーネルなら十分すぎるくらいに色々盛り込まれていますから。とりあえず、最低でもKernelが生きていてWDTを随時叩いてるという話になりますので、そうなると、別の要因・要はハードウェアの問題なのかな。と。
単に通信周りを受け持つ「プロセスが」止まったんでしょう。そのプロセスがどのくらいの範囲をカバーしてたかはともかく
> 最下位のidleタスクでウォッチドッグを叩く> それが止まったら再起動> 単純に止まったものを再起動させるのがウォッチドッグ・タイマー
昔、RFIDのリーダが機能しなくなる問題の解析をやった事がありましたが、その原因がもろにidleタスクでWDTを叩けなくなる→WDTタイムアウトによる再起動でした。WDTを叩くなんてインナーループの中でやるもんだろう、「idleタスクでWDTを叩く」なんて設計は何の冗談なんだろうか、って思いましたが。
Linuxをなんだと思ってんだろ
Linuxが死んだんではなく、その上で動く1プロセスに色々全てが集約されててそいつがクラッシュなりフリーズしたんではないかな。イベントループ回ってるか程度でもいいからウォッチドック位は付けとけはホントその通りだよなぁ…宇宙線の影響で再起動があり得るような環境なら必須じゃないのかと
あれもおかしいこれもおかしい開いた口が塞がらないなんて素人が上から目線で指摘しても意味なくてどういう条件がそろったらまともなプロジェクトがこういうミスを犯すだろうかを考えた方がまだマシだよね
Linuxカーネル使っておきながら、システム全体が飛ぶって所に開いた口が塞がらないのですが。まさか、データ格納するストレージをケチった上に/var とか/home あたりにデータ書くようにしたんで起動しようにも起動できなくなってるんじゃないかとか。
この発言の背景には、衛星の打ち上げに大きな費用がかかり失敗したときの損失が大きいから高品質であるはずだという仮定があるのだと思います。
ところが相乗り衛星だと打ち上げ費用が300万円ということもあり
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
クラッシュって… (スコア:1)
Linuxカーネル使っておきながら、システム全体が飛ぶって所に開いた口が塞がらないのですが。
まさか、データ格納するストレージをケチった上に/var とか/home あたりにデータ書くようにしたんで起動しようにも起動できなくなってるんじゃないかとか。
# 真面目に考えたら、別にデータ専用のストレージを置きますよね。
# 回路コスト考えたら数百ドルも増えやしないだろうに…
で、ウォッチドッグタイマも入れないなんて、この手のシステムで考えられないですしね。
信頼性を考えたら、CPU備え付けだけじゃなくて外部にウォッチドッグ入れるとかするものですが。
Re:クラッシュって… (スコア:2)
「システム全体が飛ぶ」とはどこにも書かれてないと思いますが…
「運良く再起動することを期待する」と書かれているぐらいですから、「起動しようにも起動できなくなってる」という想像はちょっと的外れ
たぶん、Linux システムは稼働しているが、「テレメトリ情報を送信するプロセス」だけがクラッシュしているんじゃないでしょうか。
ストーリーに挙げられている「惑星協会のブログ」をざっと読んだんですが、
「運良く再起動することを期待する」理由として、
「リブートしたらbeacon.csvはクリアされる」って書いてます。
ブート時の処理でbeacon.csvを削除する処理が入っている可能性もありますが、それよりも
csvはtmpfsに書き込むようにしていて、tmpfsは容量32MBしかとっておらず、
プログラムはディスクフルを想定していない、
とかそんなとこかなーとか想像してしまいました。
#状況確認用のデバッグログを/tmpに出力するようにしておく、というのは自分にとっては「あるある」です。本番で削除するのを忘れないようにしないと…
Re: (スコア:0)
再起動指示受け付けないってあるから、他も巻き込んでるような。
mmapでファイル扱ってパンクとか。
でもcsvに15秒に一回書き込みで使わないよな。
Re:クラッシュって… (スコア:1)
今回のやつがそうだとは断定できないけどマルチタスクにおけるウォッチドッグタイマというのは結構めんどくさい
・各プロセスが正常に動作しているか監視するタスク
・監視タスクが異常を検出せず、自身が正常に動作していたら外部ウォッチドッグを叩く
監視条件に間違いや漏れがあったらアウト。経験少ないと組み合わせ爆発起きやすい実装しちゃうことも間々あるものです。
Re: (スコア:0)
最下位のidleタスクでウォッチドッグを叩く
それが止まったら再起動
単純に止まったものを再起動させるのがウォッチドッグ・タイマー
Re:クラッシュって… (スコア:1)
そうなんですが、大抵の…Linuxカーネルなんか特に…Kernel Panicになったら、WDT叩かなくなるのでWDTが起動して強制再起動云々に入るし、そこまで行かないとしたら、地上との送受信を担当するタスクまで停まるというのが何なんだろうという感じがあるんですよね。
そこら辺の対策のためのコードというのは、Linuxカーネルなら十分すぎるくらいに色々盛り込まれていますから。
とりあえず、最低でもKernelが生きていてWDTを随時叩いてるという話になりますので、そうなると、別の要因・要はハードウェアの問題なのかな。と。
Re: (スコア:0)
単に通信周りを受け持つ「プロセスが」止まったんでしょう。
そのプロセスがどのくらいの範囲をカバーしてたかはともかく
Re:クラッシュって… (スコア:1)
> 最下位のidleタスクでウォッチドッグを叩く
> それが止まったら再起動
> 単純に止まったものを再起動させるのがウォッチドッグ・タイマー
昔、RFIDのリーダが機能しなくなる問題の解析をやった事がありましたが、その原因がもろにidleタスクでWDTを叩けなくなる→WDTタイムアウトによる再起動でした。WDTを叩くなんてインナーループの中でやるもんだろう、「idleタスクでWDTを叩く」なんて設計は何の冗談なんだろうか、って思いましたが。
Re: (スコア:0)
Linuxをなんだと思ってんだろ
Re: (スコア:0)
Linuxが死んだんではなく、その上で動く1プロセスに色々全てが集約されててそいつがクラッシュなりフリーズしたんではないかな。
イベントループ回ってるか程度でもいいからウォッチドック位は付けとけはホントその通りだよなぁ…
宇宙線の影響で再起動があり得るような環境なら必須じゃないのかと
Re: (スコア:0)
あれもおかしいこれもおかしい開いた口が塞がらないなんて素人が上から目線で指摘しても意味なくて
どういう条件がそろったらまともなプロジェクトがこういうミスを犯すだろうかを考えた方がまだマシだよね
Re: (スコア:0)
Linuxカーネル使っておきながら、システム全体が飛ぶって所に開いた口が塞がらないのですが。
まさか、データ格納するストレージをケチった上に/var とか/home あたりにデータ書くようにしたんで起動しようにも起動できなくなってるんじゃないかとか。
この発言の背景には、
衛星の打ち上げに大きな費用がかかり
失敗したときの損失が大きいから高品質であるはずだ
という仮定があるのだと思います。
ところが相乗り衛星だと打ち上げ費用が300万円ということもあり