要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法(例あり)、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは? 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ(MSR) アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3
Catalyst を POE で動かす Engine の Catalyst::Engine::HTTP::POE という実装が CPAN にあります。"Single-threaded multi-tasking Catalyst engine " だそうです。"Single-threaded" と言いつつも実装を覗いてみると環境変数 CATALYST_POE_MAX_PROC を 1 よりも大きく設定することで prefork する実装になってます。POEシングルスレッドではアプリケーション内で発生するブロックを避けることが難しいのでそのための実装じゃないかなと思います。 ところでこの Catalyst POE エンジン、prefork の実装はどのように行っているかというと POE から prefork と名の付いたイベントが発生するとおもむろに子プロセスを生成する、というのもの。複数の
シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい!と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
この文書はなんですか? この文書は*nix系のシステムにおけるプロセスやシグナルなどについて説明することを目的に書かれました。「プロセスとかよくわかってないからちゃんと知りたいな」みたいなひとたちが想定読者です。 書いているあいだは gist で管理されていたのですが、ボリュームが大きくなったので github で管理するように変えました。 目次 導入 プロセスの生成 プロセスとファイル入出力 ファイルディスクリプタ preforkサーバーを作ってみよう ゾンビプロセスと孤児プロセス シグナルとkill プロセスグループとフォアグランドプロセス epub と pdf epub化したもの、pdf化したものが release ディレクトリに入っています。thanks to mitukiii & moznion! ライセンス この 作品 は クリエイティブ・コモンズ 表示 - 継承 3.0 非移
月末にcronを実行したいと思いcrontabに設定を書こうとしたところ、月初のように単純には書けないことに気づきました。 月初だと以下のように「毎月1日に」と書けばいいのですが、 0 0 1 * * 実行したいコマンド月末は30日の場合もあるし2月はうるう年も考慮する必要があります。 調べてみたことろ、testコマンドとdateコマンドを組み合わせて「28日から31日の間で翌日が1日だったら実行する」という設定を書けばいいみたいですね。 0 0 28-31 * * /usr/bin/test $(date -d '+1 day' +%d) -eq 1 && 実行したいコマンド勉強になりました。 参考crontabの書き方 | server-memo.netLinux - testコマンドとcronを組み合わせ、月末にバッチを動かす - Qiita
課題 /tmpと/var/tmpどっちも大体一緒だからいいんじゃないかと思って/tmpにファイルをつくろうとしたら、プログラムが使用するものは/var/tmpにと叱られた。確かに、基幹系システムのディストリビューションだと何故か/var/tmp派の人が多かった気がする。じゃあ、linux系特有の宗派の問題なのか?と思い調べてみた。 何が他のディレクトリと違うか 通常のディレクトリは、基本的にはファイルは削除しない限り消えない。 /tmpに関しては再起動するとファイルが綺麗さっぱり無くなる。 /var/tmpは再起動しても消えないがいつの間にかファイルが消えることがある。 うーん、やはり使用してきたディストリビューションのルールか、業務の慣例的なルールなのかなぁ。 やはり/tmpと/var/tmpは宗教論争なの? そういうわけではないらしい。FHS(Filesystem Hierarchy
USP 友の会勉強会 2013/12/22 AWK 一行野郎百裂拳 Normal Action-less 1 awk '{print $0}' awk '4' ファイルの中身を書き出す。 ≒ cat 2 awk '{}' awk '' 何も表示しない。 ≒ cat > /dev/null 3 awk '{print NR, $0}' awk '$0 = NR " " $0' 行番号を付ける。 ≒ cat -n 4 awk 'NR <= N {print $0}' awk 'NR <= N ' 最初の N 行を抜き出す。 ≒ head -n N 5 awk 'NR == N , NR == M {print $0}' awk 'NR == N , NR == M ' N 行目から M 行目を抜き出す。 6 awk 'NR >= N && NR <= M {print $0}' awk 'N
LinuxやUNIXでパフォーマンスを監視する際にはお約束とも言えるvmstatコマンド。 どの現場でもよく使われるものだが、今回はこのコマンドで覚えておきたい使い方を紹介する。 なお、この内容はCentOS 7にてバンドルされている「procps-ng 3.3.9」のバージョンのものを用いている。 1.基本的な使い方 オプション無しで実行すると、以下のように現時点でのパフォーマンス情報が出力される。 vmstat [root@test-centos7 ~]# vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 80556 128 13915
topコマンドといえば、よくLinuxのパフォーマンス状態をモニタリングするために利用されているコマンドだ。 今回は、そんなtopコマンドで覚えておきたい使い方14個を紹介する。 なお、検証で使用したtopコマンドはCentOS 7 で利用している「procps-ng version 3.3.9」のものとなっている。 1.基本的な使い方 基本的には、オプション無しで以下のようにコマンドを実行する。 top top - 07:21:06 up 4 days, 17 min, 4 users, load average: 0.00, 0.00, 0.00 Tasks: 186 total, 1 running, 185 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0
$ top # CPU使用率順にソート $ top -a # メモリ使用率順にソート $ top -p [PID] # 特定のプロセスを監視 $ top -d1 # 1秒ごとに更新 操作方法 Shift+o: 表示された特定のキーを押してEnterすると任意の列でソートできる Shift+p: CPU使用率順にソート Shift+m: メモリ使用率順にソート ヘッダーの見方 load average top - 08:42:47 up 2min, 2 users, load average: 2.76, 0.76, 0.27 # 現在時間 サーバーの ログイン 1分 5分 15分 # 稼働時間 ユーザー数 間の単位時間あたりの待ちタスク数
システムを運用していく上で cron を使う場面はよくありますよね 処理をスケジュール実行したい時にとても便利です そんな cron ですが、最近仕事で作業しているときに ntpdate でシステム時刻を変更した後に cron で設定した時刻になってもジョブが実行されないという問題が見つかりました 全てのジョブが実行されていないわけではなく一部のジョブは実行されているようでした また、時刻を変更した後に crond を再起動すれば全てのジョブが正常に実行されるようになりました 幸い、実運用ではなくてシステムテスト中に見つかった問題なのでまだよかったんですが、運用している環境で同じ問題が起きたら相当マズイですよね そもそも ntp の時刻同期でシステム時刻が修正された場合にも同じ問題が起きそうじゃないですか? ググっても同じような事象は見つからず、社内のメンバーにも聞いてみても cron で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く