実行中プログラムのイメージを得る - tmtms のメモ
Twitter見てたらこんなこと言ってる人がいました。 Unix で実行中の実行ファイルのパスを確実に得る方法はない、というのは FAQ だと思うけど、実際にやりたいことは自分自身を別プロセスで新たに立ち上げたいということなので、メモリにロード済の自分自身から別プロセスを作る手段はないんだろうか— Yusuke Endoh (@mametter) 2017年10月25日 昔自分もそんなこと考えたなーと思いつつ、Linuxなら /proc/<pid>/exe が実行ファイルへのリンクになってるんで、 環境によるような気もするけど、自分の実行ファイルのパスは /proc/pid/exe から取れないですかね。— とみたまさひろ (@tmtms) 2017年10月25日 と言ってみたら、 Linuxならその手が使えますが、現在実行中の実行ファイルでも削除できちゃいますから、パス名を得る完璧な方法
ptraceシステムコール入門 ― プロセスの出力を覗き見してみよう！ - プログラムモグモグ
他のプロセスを中断せずに、その出力をミラーリングして新しくパイプで繋ぐ、そんなことはできるのでしょうか。 straceやgdbといったコマンドは一体どういう仕組みで動いているのでしょうか。 ptraceシステムコールを使い、プロセスが呼ぶシステムコールを調べて出力を覗き見するコマンドを実装してみたいと思います。 ptraceシステムコール Linuxを触っていると、いかにプロセスを組み合わせるか、組み合わせる方法をどれだけ知っているかが重要になってきます。 パイプやリダイレクトを使ってプロセスの出力結果を制御したり、コードの中からコマンドを実行して、終了ステータスを取得したりします。 プロセスツリーやプロセスグループを理解し、シグナルやnohupコマンドを使ったりします。 プロセスの扱いに慣れると疑問に持つのがstraceやgdbの仕組みです。 プロセスの実行しているシステムコールを出力し
Linux シグナルの基礎
TLPI (The Linux Programming Interface) 再々。 TLPI の輪読の際に @matsumotory よりシグナルセットあたりをまとめるようにと指令が出たので、拙遅な感じでまとめました。 シグナルとは プロセス間通信の一種。「プロセスにシグナルを送信すると、そのプロセスの正常処理に割り込んで、シグナル固有の処理(シグナルハンドラ) が実行される」プロセス側では、シグナルを受信した際の動作(シグナルハンドラ) を設定することや、シグナルをブロックすることも可能。 コンソールで、プロセスを終了させるためにkill -9 <PID>とかCtrl+Cとかした際にも、対象プロセスにシグナルが送信されている。 ちなみに、PID「1」の init や systemd にkill -9 1しても何も起らない。(そういえば昔、oom-killer に init を殺された覚
OOM Killerにであったら何をするべきか?
OOM killerで大事なプロセスが殺される。困りますね。。 google で OOM Killerと入力すると 「無効」とか補完されます。しかしどうするのが良いのか、あまりよく説明されている記事がみあたらなかったので自分の考えをメモしておきます。 OOM Killer の目的は何か? まずは何故OOM Killerが発生しているのかについて、ざっくりイメージをつかみましょう。linux kernelはプロセスからの「メモリくれ」という要求に対してたぶん足りそうだという場合に「OK」といって渡します。実際のメモリ割り当てはアクセスが発生するタイミングまで遅延させます。これを遅延アロケーションといい、だいたいにおいてうまく動きます。ただし必ずうまくいくと保証されているわけではないので破綻することがあります。 OOM Killerはこの遅延アロケーションが破綻しそうなときに、適当にプロセスを
共有ライブラリのアップデート時にプロセスの再起動はいつ必要か
共有ライブラリのアップデート時、対象のライブラリが起動中のプロセスから利用されているかを見て、プロセスの再起動を行うかどうかの判断をしている。 例えばこんなのとかですね。 $ sudo grep libssl.so.1.0.1e /proc/*/maps | cut -d/ -f3 | sort -u | xargs -r -- ps uf プロセスを再起動すれば、更新されたライブラリが使用されるという認識で居るのだけれど、実際にそうなのか調べたことがなかった。 ライブラリをアップデートしたときに、どのタイミングで差し変わるか気になったので調べてみた。 共有ライブラリのサンプル プロセス再起動時 まずは、普通に再起動を行ってみる。 $ ./test Hell World PID is 16856 Press Any Key To Exit... 別のターミナルで maps を参照してみる。
fork()は失敗するんだぜ、覚えときな
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか？ マジで分かってるか？ マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか？ そうだよ。お前多分、"-1"（forkのエラー通知）をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
Linux、i/o待ちしているプロセスを見極める - goungoun技術系雑記帳
vmstat 1 して、ボ〜っと眺めてると $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 1 44 21620 140900 487244 0 0 0 444 270 195 0 0 95 5 procs の b が「割り込みを禁止しているプロセスの数」で これは 0 が望ましいわけですが。 0以外になったとき「誰が犯人だ！」と思うのです。 犯人探し 多分手抜きです。 ps で出力される STAT が D のプロセスが io待ち のプロセスである。 ということで、１秒周期で D のプロセスを出力するスクリプトがこれ。 (while true; do
コンソールから切れたプロセスを標準出力につなげなおす - 絶品ゆどうふのタレ
不慣れな環境を不意にいじった時にあるあるネタ。 とりあえずー とか言って勢いで書いたsetupスクリプトを実行してみたら意外と時間かかって、 ちょっと目を離した隙にsshの接続が切れちゃいました！ 。。。ありますよね。ほんとよくありますよね。 そうなる予感はあったんだ なんて後の祭りです。ふとした油断から、screenもnohupすらも使わずにやってしまって、こんなことに。 shellがHUPしなかったからプロセスは生きてるものの、ログが見れないから進行状況がわからない。 うまく行ってるのかどうかモヤモヤした気持ちのまま、プロセスが終わるのをじっと待つ。。。 まぁ実に切ないです。 こんな時、いつも思うこと。 このプロセスの出力、もっかいstdoutに繋げられたらいいのに。。。 はい。というわけでつなげましょう。 長い前座ですみません。 切り離したプロセスを用意 #!/bin/bash wh
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.nces.is.nagoya-u.ac.jp/NEXCESS/blog/index.php?catid=44&blogid=5