サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ストレッチ
doi-t.hatenablog.com
二十五日半狂乱、6日目(の分...orz)の記事 Cのエラーハンドリングを毎回やるのは面倒だ! 前回も言ったが、Cではエラーハンドリングに戻り値とerrnoを用いる. それはそうと例外設計において"無視"は大罪である. だから、関数を呼び出したら戻り値は漏らさずチェックすべきだ. ということで、例えば以下のように逐一戻り値をチェックする. if(send(sockfd, buf, len, 0) < 0){ ERROR("send"); exit(1); } あぁ、面倒だ. 一体コードのどの部分が正常系の処理なのか? ほとんどエラーハンドリング*1で埋め尽くされるじゃないか. そもそもエラーハンドリング部分に書くのは毎回同じコードだし、コードの繰り返しは防ぎたい. エラー処理部分をラッピングして楽をする unpv12eの中でラッパーを被せることによってこの面倒を回避する方法を知った. in
二十五日半狂乱、2日目の記事. 実行中のプロセスをkillしたいが、対象のプロセスをkillすると子プロセスがゾンビ化しちゃうからプロセスツリーを丸ごとkillしたくなった. どうせならkillコマンドっぽくプロセスIDで指定して、指定したプロセスをrootとしてツリーの葉から根に向かってツリー上のプロセスをkillして回りたい. 車輪の再発明の匂いがプンプンするので、「そんなのこうすれば一発じゃん.」ってのがあったらご指摘いただけたらと思います.(※議論し尽くされていました) 追記:後日、↑のリンク先にある"より良いコード"について書いたので、こちらも参考をば. コードはgithub上に上げた. doi-t/killpstree READMEにも書いたけど、目的を達成するシェル関数*1は気持ちいいくらいにシンプル. killpstree(){ local children=`ps --p
前回、「次回もシグナルのことを書く」と書いたのでシグナルのことを書く*1. ソケットプログラミングの落とし穴は色々あるけど、ここでは個人的に嵌ったシグナル関連の落とし穴に関して書き殴る. 結論から書くと、コネクションが切れたソケットに書き込み(send(2)とかwrite(2)とか、同じものだけど)を行うと、SIGPIPEシグナルが発生してプロセスが強制終了するので、きちんとSIGPIPEシグナルをハンドリングしておこうという話. 以下では、サンプルコードを使って、実際にパイプの書き込み先をkillして、SIGPIPEの発生を疑似体験してみる. SISGPIPEを受けたプロセスの挙動とソケットプログラミングでの対応策 「sigpipe」で検索すると、同様の話はいくらでも記事になっていて、例えば、 「私の書いたサーバが突然死するんです。どうしてでしょうか」という質問を受けることがあります。こ
前回(g++)と前々回(gcc)のサンプルコードを使ったC++のマングリングや"C"リンケージに関するメモ. nmコマンドでサンプルコードのシンボルテーブルを覗いた後に、C++からCの関数を呼び出す場合のサンプルコードを示す. 特にリンケージ周りの説明は正確性を欠いているやもしれませんのでご容赦下さい.より詳細な説明は参考リンク等を参照して頂ければと思います. nmコマンド nm は、UNIXや類似のオペレーティングシステムに存在するコマンドであり、バイナリファイル(ライブラリ、実行ファイル、オブジェクトファイル)の中身を調べ、そこに格納されているシンボルテーブルなどの情報を表示する。デバッグに使われることが多く、識別子の名前の衝突問題やC++の名前修飾の問題を解決する際に補助として用いられる。 GNUプロジェクトでは、高機能の nm プログラムを GNU Binutils パッケージの一
手元のgcloudに紐付く複数のaccount/project/k8s cluster/k8s namespaceを持っている場合、とにかくどのアカウントで、何のロールで、どこのプロジェクトのどのクラスタに向かってgcloudやkubectlを叩いているのか都度確認しながら作業することになる。gcloudとkubectlはそれぞれconfigというリクエストの投げ先(context)の設定をするのに重要なサブコマンドを持っていて、これらを正しく設定しないと所望のプロジェクトなりクラスタにアクセスできない。サブコマンドがどちらもconfigという名前なので、慣れてくると覚えるキーワードが少なくて大変良いが、頭の中で二つを整理しないうちは似たようなコマンドが色々出てくるので何が何やらわからなくなってくる。 また、個々の設定方法はコマンドのhelpなりドキュメントを見ればわかるが、最初は脳内に逆
二十五日半狂乱4日目(の分)の記事 前回引用したkilltreeスクリプトの中に以下のようなコードがあった. local _sig=${2:-TERM} この${2:-TERM}は、変数展開されたタイミングで、$2に値が設定されていない場合にTERMを出力する. すなわち、結果的に$2が空だった場合は変数_sigにTERMが代入される. なのでkilltreeは第二引数でシグナルを指定せずに実行したらデフォルトでkill -TERM [pid]が実行される. $ bash killtree.bash 4003 kill -TERM 4004 kill -TERM 4005 kill -TERM 4006 kill -TERM 4007 kill -TERM 4008 kill -TERM 4003 [2]+ Stopped bash mkpstree.bash 手元にあるUNIXシェルスク
GKE上に立ち上げている自前のkubernetesのClusterは、一番安いという理由だけでg1-small*1を使い続けていた。しかし、いざ複数のPodを追加したりし始めると、Nodeのリソース不足が原因で色々ハマったので、そこで覚えた細かいデバッグ手法を例のごとく逆引き辞書っぽくメモしていく。ついでにリソースとは無関係なkubernetesのネットワーク関連でハマったこともメモ。すでに使い込んでいる人にとって目新しいものはない気がする。 以下、例となっているPodのデプロイは、状況を再現しやすいという理由だけで手前味噌のprometheus実験レポジトリを元に行っているのでprometheusが云々と多少言っているが、基本的にPodの内容がなんであれ、リソースが足りなくなった場合に何が起こって、kubectlで何を確かめれば良さそうか、という点を中心に書き下していく。 Check k
(2019/06/29追記) 実践的、網羅的かつ簡潔にまとまったドキュメントを見つけたのでメモ(日本語訳もある)*1。 github.com このtipsはこれからLinuxを使っていく必要がある人、特に端末操作に苦戦している人、もしくは端末操作に対して嫌悪感すら抱いている人に向けて書いたものです.きっかけはRebuild.fmのep41*2.少しでも端末操作が楽しく気持ち良くなればこれ幸い. rebuild.fm Linuxターミナルtips 今回は、キーボードショートカットを中心に極基本をば。 ちなみにWindows キーボードショートカットキーの一覧 ちなみにMac CheatSheet commandボタン長押しで、起動しているアプリのショートカット一覧が表示されるアプリらしい Linux(Ubuntu) ターミナル起動 ctrl+alt+t 開いた後のカレントディレクトリはホーム
二十五日半狂乱、5日目(の分)の記事 C言語における関数のエラーハンドリングには戻り値およびerrnoを使うが、自分が読んだ文法書などのサンプルコードではエラーが起こった場合の処理が、大体がperror("fopen"); exit(1);のような感じのもので、まぁ小さいサンプルコードをいくつも書いていたうちはこれでも良かった. だけど、ある程度以上の規模のアプリケーションを書き始めて、コードがそれなりに大きくなってくると一体どこのエラーなのか一目でわからなくなってくる. エラーメッセージを自由に設定して、関数名や行番号も表示したい.それに何度も書くのでできるならお手軽に書きたい. そんな事情で、一年前くらい前に以下のようなエラーメッセージ用の関数を作った.コンパイラはgccを使用する. 改めて見ると現在時刻は完全に蛇足な感じがするが、まぁ割と重宝している. 上記サンプルは実行すると、現在
二十五日半狂乱3日目の記事 もはや、Advent Calendarでもなんでもなくなっているけど、そんな悲しい現実はさておいて. 前回の話がstackoverflowですでに議論され尽くされていて、解答の一つに自分のスクリプト似た構造のシェルスクリプトがあった. #!/bin/bash killtree() { local _pid=$1 local _sig=${2:-TERM} kill -stop ${_pid} # needed to stop quickly forking parent from producing child between child killing and parent killing for _child in $(ps -o pid --no-headers --ppid ${_pid}); do killtree ${_child} ${_sig}
(2019/06/29追記) 実践的、網羅的かつ簡潔にまとまったドキュメントを見つけたのでメモ(日本語訳もある)*1。 github.com このtipsはこれからLinuxを使っていく必要がある人、特に端末操作に苦戦している人、もしくは端末操作に対して嫌悪感すら抱いている人に向けて書いたものです.作成の経緯はその1の冒頭および注釈に書きました. 前回の話題 ファイルを見つける(locate, find) ファイルの中身を調べる(grep) Linuxターミナル、コマンドtips その2: ファイルを見つける(locate, find)、ファイルの中身を調べる(grep) 今回の話題 コマンドや自作プログラムの入出力をコントロールする stdin, stdout, stderrの理解とターミナル、キーボードとの関係 リダイレクト: ファイルから読み出す、ファイルに書き出す パイプ: コマン
過去に何回かシグナルに関する話をしたが、今回と次回もシグナルの話にしようと思う. シグナルそのものについてはsignal(7)のmanページを参照する. ここでは、シグナルを捕捉する側の話をする. 主に移植性の問題で、signal(2)ではなくsigaction(2)を使うべきだが、sigaction(2)はそのままだと使いにくいので、ラッピングして使い易くして、ちょっとだけ遊んでみた. signal(2)は使うな、sigaction(2)を使え。 POSIXがそう言っている. signal() の動作は UNIX のバージョンにより異なる。 また、歴史的に見て Linux のバージョンによっても異なっている。 このシステムコールの使用は避け、 代わりに sigaction(2) を使用すること。 Man page of SIGNAL sigaction(2)のラッパー関数 Gistにサン
このページを最初にブックマークしてみませんか?
『doi-t.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く